Mirth 4.5.0 removes 
 encoding in Webservice call

[MirthRanger]

We have just upgraded to 4.5.0 and found that the encoding in the Webservice SOAP body is being replaced with the 0x0d character when written out the TCP stream - as seen by a wireshark capture. It didn't' happen in 4.4.2. Has anyone else seen this?

[medir]

We have detected the same issue and also noticed that in version <= 4.4.2, HL7 responses encapsulated in XML (Web Service Listener) had the segment code (CR) represented as 
. Starting from version >= 4.5.0, we receive a different encoding for CR 0x0D.

We are attaching the files where this change in encoding can be seen:
output_mc_v451.txt
output_mc_v442.txt

[tonygermano]

This does look like a bug. What I saw when trying to parse the resulting xml, and then confirmed with this SO post, the literal carriage return gets converted to a linefeed, making the hl7 no longer valid. So, it does need to be encoded (either as 
 or 
) to retain the same value when parsing.

[mrreview]

We're also facing this exact problem.

[nicovn]

There is indeed a difference, but I don't have any issues parsing the HL7 ACK message in the response transformer in Mirth...

`// Use HL7 ACK from SOAP response envelope

var hl7ACKMessage = msg.::Body.::acceptMessageResponse.*.toString();

// Convert the HL7 ACK (string) to a Mirth HL7 v2 XML representation for further processing
msg = SerializerFactory.getSerializer('HL7V2').toXML(hl7ACKMessage);`

Bet Regards

Nico

Check out our latest and free FHIR search tool: FHINDR - https://github.com/amaron-team/fhindr

[MirthRanger]

The issue we are encountering is for Webservice to our EMR. We are sending an encoded HL7 V2.x via SOAP webservice. Whilst we are sending the segment delimiter as encoded ie the mirth webservice sending is decoding it to 0x0d; as captured with TCP dump. This shouldn't happen. When our EMR receives, per the XML standard 0x0d is returned as 0x0a and so the HL7 encoding of the message in the payload is broken. Nextgen have confirmed this is a problem and planning to fix in 4.6.0.

Thank you for investigating,

Mark

[medir]

Hello @MirthRanger, do you have a link of the issue you mention? I would like to track it.

Nextgen have confirmed this is a problem and planning to fix in 4.6.0.

Thank you.

[nicovn]

Hi Mark,

FYI - the segment separator sent via the Web Service Sender is different depending on how you encode the message in the template in Mirth.

e.g.

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="http://ws.connectors.connect.mirth.com/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <tns:acceptMessage> <arg0><![CDATA[${message.encodedData}]]></arg0> </tns:acceptMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

-> the above will send line feed (0A) as segment character

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="http://ws.connectors.connect.mirth.com/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <tns:acceptMessage> <arg0>${XmlUtil.encode(${message.encodedData})}</arg0> </tns:acceptMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

-> if using XmlUtil.encode the segment separator will be carriage return (0D)

Best Regards

Nico

Check out our latest and free FHIR search tool: FHINDR -

[MirthRanger]

Hi Nico,

Thank you for investigating further. I am doing the XML encoding in the outbound, which is encoding with the expected XML encoding . This can be seen in the Sent message window in Mirth administrator, for example:

The issue seems to be that when Mirth writes this out the TCP stream it is reverting it back to 0d, as you see in your packet capture. We should be seeing at the position of segment delimiters in the capture. Seems like the Webservice sender TCP writer is decoding the XML in the payload prior to sending to the endpoint - it should be leaving the encoding in place.

Our problem then arises at our EMR, which appears to be interpreting the XML to the standard:

https://www.w3.org/TR/REC-xml/#sec-line-ends

2.11 End-of-Line Handling
XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).

To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.

=================

So our EMR is reading in 0a and that is breaking the HL7 message payload in the XML. Based on packet captures I have done this seemed to start in 4.5.0

Cheers, Mark