Why ACKGenerator creates PID segment? #4588

tom08zehn · 2021-06-10T15:58:31Z

tom08zehn
Jun 10, 2021

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 · 2021-06-14T06:53:57Z

tom08zehn
Jun 14, 2021
Author

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.

0 replies

tom08zehn · 2021-06-14T08:47:48Z

tom08zehn
Jun 14, 2021
Author

Seems that using this method works better using isXML=true: http://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?

4 replies

pacmano1 Jun 15, 2021
Collaborator

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 Jun 15, 2021
Collaborator

Using this form of the generator:

tom08zehn Jun 15, 2021
Author

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 Jun 15, 2021
Collaborator

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

tom08zehn · 2021-06-15T14:58:56Z

tom08zehn
Jun 15, 2021
Author

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)"?

4 replies

tonygermano Jun 15, 2021
Collaborator

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 Jun 15, 2021
Author

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 Jun 15, 2021
Collaborator

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 Jun 15, 2021
Author

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

tom08zehn · 2021-06-15T20:50:43Z

tom08zehn
Jun 15, 2021
Author

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>

8 replies

tom08zehn Jun 15, 2021
Author

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 Jun 15, 2021
Author

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 Jun 15, 2021
Collaborator

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 Jun 15, 2021
Author

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 Jun 16, 2021
Collaborator

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 · 2021-06-15T21:05:08Z

tom08zehn
Jun 15, 2021
Author

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

2 replies

tonygermano Jun 15, 2021
Collaborator

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

tom08zehn Jun 15, 2021
Author

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

tom08zehn · 2021-06-16T09:29:52Z

tom08zehn
Jun 16, 2021
Author

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", ""));

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Why ACKGenerator creates PID segment? #4588

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 18 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Why ACKGenerator creates PID segment? #4588

tom08zehn Jun 10, 2021

Replies: 6 comments · 18 replies

tom08zehn Jun 14, 2021 Author

tom08zehn Jun 14, 2021 Author

pacmano1 Jun 15, 2021 Collaborator

pacmano1 Jun 15, 2021 Collaborator

tom08zehn Jun 15, 2021 Author

pacmano1 Jun 15, 2021 Collaborator

tom08zehn Jun 15, 2021 Author

tonygermano Jun 15, 2021 Collaborator

tom08zehn Jun 15, 2021 Author

tonygermano Jun 15, 2021 Collaborator

tom08zehn Jun 15, 2021 Author

tom08zehn Jun 15, 2021 Author

tom08zehn Jun 15, 2021 Author

tom08zehn Jun 15, 2021 Author

tonygermano Jun 15, 2021 Collaborator

tom08zehn Jun 15, 2021 Author

tonygermano Jun 16, 2021 Collaborator

tom08zehn Jun 15, 2021 Author

tonygermano Jun 15, 2021 Collaborator

tom08zehn Jun 15, 2021 Author

tom08zehn Jun 16, 2021 Author

tom08zehn
Jun 10, 2021

Replies: 6 comments 18 replies

tom08zehn
Jun 14, 2021
Author

tom08zehn
Jun 14, 2021
Author

pacmano1 Jun 15, 2021
Collaborator

pacmano1 Jun 15, 2021
Collaborator

tom08zehn Jun 15, 2021
Author

pacmano1 Jun 15, 2021
Collaborator

tom08zehn
Jun 15, 2021
Author

tonygermano Jun 15, 2021
Collaborator

tom08zehn Jun 15, 2021
Author

tonygermano Jun 15, 2021
Collaborator

tom08zehn Jun 15, 2021
Author

tom08zehn
Jun 15, 2021
Author

tom08zehn Jun 15, 2021
Author

tom08zehn Jun 15, 2021
Author

tonygermano Jun 15, 2021
Collaborator

tom08zehn Jun 15, 2021
Author

tonygermano Jun 16, 2021
Collaborator

tom08zehn
Jun 15, 2021
Author

tonygermano Jun 15, 2021
Collaborator

tom08zehn Jun 15, 2021
Author

tom08zehn
Jun 16, 2021
Author