Why ACKGenerator creates PID segment?

[tom08zehn]

GIVEN my channel settings: "Source" tab under "Source Settings", Response is set to: "RESPONSE" (referring to $r("RESPONSE"))
AND GIVEN my Preprocessor script contains the line: $r("RESPONSE", ACKGenerator.generateAckResponse(connectorMessage.getRawData(), "AA", ""));
WHEN inbound message is:

MSH|^~\&|HIS||BAZ||20200226085612||ORM^O01|5eb55792-8efc-4a28-ae6d-26b0e37a0c88|P|2.5
PID|||11111111||Doe^Jane||19751209000000|M
PV1|||||||||||||||||||22222222
ORC|NW|33333333|||||||||||^Foo^^Bar
OBR||||||20210609163000||||||||||^Simpson^March^^^^Dr.

THEN the response contains an empty PID segment:

MSH|^~\&|SPM||HIS||20210610174837||ACK^O01^ACK|20210610174837|P|2.5
PID
MSA|AA|5eb55792-8efc-4a28-ae6d-26b0e37a0c88

Why?

Compared to:
GIVEN my channel settings: "Source" tab under "Source Settings", Response is set to: "Auto-generate (Before processing)"
THEN the response contains no PID segment

Mirth v3.11.0

[tom08zehn]

Also using messageinstead of connectorMessage.getRawData() produces the same result.

My first thought was that maybe the ORM message is the root cause but on the other hand it works perfectly (no PID segment) when setting the channel to "Auto-generate (Before processing)".

Sorry for pushing again... I didn't find the source code - wanted to check how Mirth itself does it. Could someone help to find it?

Many thanks.

[tom08zehn]

Seems that using this method works better using isXML=true: http:https://javadocs.mirthcorp.com/connect/3.11.0/user-api/com/mirth/connect/server/userutil/ACKGenerator.html#generateAckResponse-java.lang.String-boolean-java.lang.String-java.lang.String-java.lang.String-java.lang.String-

But still, there are issues:

• no linebreak before MSA segment
• wrong message control ID (just 1)

var ack = ACKGenerator.generateAckResponse(message, true, "AA", "using_isXML", "yyyyMMddHHmmss", "");

/* I also tried the following but all end up with the same result:
// var ack = ACKGenerator.generateAckResponse(message.toString(), true, "AA", "using_isXML", "yyyyMMddHHmmss", "");
// var ack = ACKGenerator.generateAckResponse(connectorMessage.getRawData(), true, "AA", "using_isXML", "yyyyMMddHHmmss", "");
// var ack = ACKGenerator.generateAckResponse(connectorMessage.getRawData().toString(), true, "AA", "using_isXML", "yyyyMMddHHmmss", "");
*/

var hl7 = SerializerFactory.getSerializer('HL7V2').fromXML(ack); // good: no PID segment
$r("RESPONSE", hl7); // bad: no linebreak and wrong message control ID (just 1)

Any ideas?

[pacmano1]

I call something like this. No PID is returned. Source data type is HL7 of course.

$c('responseContent', ACKGenerator.generateAckResponse(connectorMessage.getRawData(), "AA", "Accepted for downstream processing" + $c('ackExtraText', '')));

[pacmano1]

Using this form of the generator:

[tom08zehn]

I call something like this. No PID is returned. Source data type is HL7 of course.

$c('responseContent', ACKGenerator.generateAckResponse(connectorMessage.getRawData(), "AA", "Accepted for downstream processing" + $c('ackExtraText', '')));

Yeah thanks for your reply. This is basically the same as I've tried in my first attempt. Also strange is that the PID is not returned for other inbound message types like ADT.

Still, I don't get this PID with other channel setting 🤔

[pacmano1]

Can you post your full channel export please? Or enough of it to replicate the problem.

[tom08zehn]

This is so weird, after hours of investigation I tried today:

var ack = com.mirth.connect.plugins.datatypes.hl7v2.HL7v2ACKGenerator.generateAckResponse(connectorMessage.getRawData(), false, "AA", "", "yyyyMMddHHmmss", "");
$r("RESPONSE", ack);

and still includes the strange PID segment in the response.

Could anyone lead me to the source code to see how Mirth does it when channel is set to "Auto-generate (Before processing)"?

[tonygermano]

I guess here's a good starting point:
https://github.com/nextgenhealthcare/connect/blob/3.11.0/donkey/src/main/java/com/mirth/connect/donkey/server/channel/Channel.java#L1282

And here is the User API class:
https://github.com/nextgenhealthcare/connect/blob/3.11.0/server/src/com/mirth/connect/server/userutil/ACKGenerator.java

If you trace them, they both ultimately call this to do the work:
https://github.com/nextgenhealthcare/connect/blob/3.11.0/server/src/com/mirth/connect/plugins/datatypes/hl7v2/HL7v2ACKGenerator.java#L29

[tom08zehn]

Yeah, I also just found https://github.com/nextgenhealthcare/connect/blob/3.11.0/server/src/com/mirth/connect/plugins/datatypes/hl7v2/HL7v2ACKGenerator.java#L29 and tested it but segmentDelimiter seems to be ignored... or as the XML is wrong this simply results in a wrong serialized message too.

var xmlMessage = SerializerFactory.getSerializer('HL7V2').toXML(connectorMessage.getRawData());
var xmlAck = com.mirth.connect.plugins.datatypes.hl7v2.HL7v2ACKGenerator.generateAckResponse(xmlMessage, true, "AA", "", "yyyyMMddHHmmss", "", "\r"); // explicitly provide segmentDelimiter="\r" but seems to be ignored
var hl7Ack = SerializerFactory.getSerializer('HL7V2').fromXML(xmlAck);
$r("RESPONSE", hl7Ack);

[tonygermano]

I wouldn't use the xml version. My guess is that your inbound message is using \n instead of \r as the segment delimiter, so the version is getting read as 2.5\nPID. Does this fix it?

$r("RESPONSE", ACKGenerator.generateAckResponse(connectorMessage.getRawData().replaceAll('\n', '\r') , "AA", ""));

If this is the case, you probably have the "Convert Linebreaks" option turned on in your data type properties, which is fixing it in the transformer, so you might not notice the problem, otherwise.

[tom08zehn]

Yes 🤦‍♂️ didn't expect the Mirth code to be so sensitive

[tom08zehn]

Step by step getting forward... 😁 not giving up

The following works (no PID segment) except that the ACK response has no linebreak before MSA segment:

var xmlMessage = SerializerFactory.getSerializer('HL7V2').toXML(message);
var xmlAck = ACKGenerator.generateAckResponse(xmlMessage, true, "AA", "", "yyyyMMddHHmmss", "");
var hl7Ack = SerializerFactory.getSerializer('HL7V2').fromXML(xmlAck);
$r("RESPONSE", hl7Ack);

Result:

ACK|MSH|^~\&|SPM|||||HIS|||||||20210615224410|||||||||ACK|ACK|ACK||||||||20210615224410|P||||||||||||2.5|MSA|AA|5eb55792-8efc-4a28-ae6d-26b0e37a0c88

If I omit the last step (converting ACK in XML format to HL7v2) then the resulting XML looks fine:

var xmlMessage = SerializerFactory.getSerializer('HL7V2').toXML(message);
var xmlAck = ACKGenerator.generateAckResponse(xmlMessage, true, "AA", "", "yyyyMMddHHmmss", "");
$r("RESPONSE", xmlAck);

So what's wrong when converting XML (string) message to HL7v2? Any idea why linebreak is missing

Result:

<ACK>
    <MSH>
        <MSH.1>|</MSH.1>
        <MSH.2>^~\&amp;</MSH.2>
        <MSH.3>
            <HD.1>SPM</HD.1>
        </MSH.3>
        <MSH.5>
            <HD.1>HIS</HD.1>
        </MSH.5>
        <MSH.7>
            <TS.1>20210615224859</TS.1>
        </MSH.7>
        <MSH.9>
            <MSG.1>ACK</MSG.1>
            <MSG.2>ACK</MSG.2>
            <MSG.3>ACK</MSG.3>
        </MSH.9>
        <MSH.10>20210615224859</MSH.10>
        <MSH.11>
            <PT.1>P</PT.1>
        </MSH.11>
        <MSH.12>
            <VID.1>2.5</VID.1>
        </MSH.12>
    </MSH>
    <MSA>
        <MSA.1>AA</MSA.1>
        <MSA.2>5eb55792-8efc-4a28-ae6d-26b0e37a0c88</MSA.2>
    </MSA>
</ACK>

[tom08zehn]

Maybe the magic is here:

https://github.com/nextgenhealthcare/connect/blob/master/server/src/com/mirth/connect/plugins/datatypes/hl7v2/HL7v2ACKGenerator.java#L230

Or I found a bug.

[tom08zehn]

OK, now I did a super cheap trick and replaced the XML root element <ACK> by <HL7Message>, full code:

var xmlMessage = SerializerFactory.getSerializer('HL7V2').toXML(message);
var xmlAck = com.mirth.connect.plugins.datatypes.hl7v2.HL7v2ACKGenerator.generateAckResponse(xmlMessage, true, "AA", "", "yyyyMMddHHmmss", "", "\r");
xmlAck = xmlAck.replace('<ACK >', '<HL7Message>').replace('</ACK>', '</HL7Message>');
var hl7Ack = SerializerFactory.getSerializer('HL7V2').fromXML(xmlAck);
$r("RESPONSE", hl7Ack);

Result:

MSH|^~\&|SPM|||||HIS|||||||20210616001031|||||||||ACK|ACK|ACK||||||||20210616001031|P||||||||||||2.5|
MSA|AA|5eb55792-8efc-4a28-ae6d-26b0e37a0c88

Looks fine in the first place but the trained eye sees 3x ACK in the MSH.9 field... and when taking a closer look to the XML I sent above (Result 2) then you can also see that the generated XML contains a lot of strange element names such as MSG.1 instead of MSH.9.1 - actually all child elements on 2nd level do have strange names.

Any idea how that comes? With every step coming closer it seems to get more weird 🙄

[tonygermano]

In order to serialize the XML ACK, you need to put the serializer in strict mode. Did you see my other comment about your segment delimiter on the inbound message and replacing it if it is \n? In the message browser, you can right click in the content window and make the line endings visible to see how it's coming in.

[tom08zehn]

Thanks, didn't know I can see line endings. Really useful 👍
Yes, saw it and tested: replacing \n by \r does the trick.

"Convert Line Breaks" is enabled in my channel's data type settings but no matter if I turn it on or off the result is the same.

Strange: original message clearly contains \r\n (can see it in my editor) but seems to be converted using copy & paste to send the message via Mirth GUI.

Many, many thanks, again. You really saved my day!

[tonygermano]

Glad you got it fixed. You might want to summarize the solution in a new answer so you can mark it as accepted.

The "Convert Line Breaks" doesn't actually take effect until the data is converted for the source filter/transformer, so you'll have to do it manually in the pre-processor. The HL7 spec is pretty strict that the segment delimiter must be \r but mirth has that option since it's often the case that messages don't meet the spec (especially when copied and pasted from another source.)

[tom08zehn]

Just found in the user guide: in Response Generation Properties you can set a segment delimiter... but this option has no effect unless an "Auto-generate" item has been selected in the response settings.

https://github.com/freemed/mirth/blob/master/server/src/com/mirth/connect/server/userutil/ACKGenerator.java#L116

[tonygermano]

Does your inbound message use something other than \r as the segment delimiter?

[tom08zehn]

It seems to have \r\n. Just converted to \r only but result is the same.

[tom08zehn]

Problem was that inbound message has linefeed \n line endings instead of carriage return \r.

Solution: convert \n to \r as follows and then the rest is simple as usual:

// Inbound message as HL7v2 formatted string
var inboundMessage = connectorMessage.getRawData();
// Ensure to convert message to java String in order to use replaceAll method, then replace all linefeed to carriage return according to HL7v2 standard
inboundMessage = new java.lang.String(inboundMessage.toString()).replaceAll('\n', '\r');
// Create new ACK response
ack = ACKGenerator.generateAckResponse(inboundMessage, "AA", "");
$r("RESPONSE", ack);

... or as a one-liner:

$r("RESPONSE", ACKGenerator.generateAckResponse(new java.lang.String(connectorMessage.getRawData().toString()).replaceAll('\n', '\r'), "AA", ""));