Sending ACK

[nshaik]

When the host and Mirth have ACK turned on, host is not receiving the ACK sent by Mirth. This causes the host to re-send the message until the max no. of retires.

Mirth does receive and process the message(s) and the problem could be at the host end.

What port does Mirth use to send the ACK back to the host?

Thanks in advance!

[chrisl]

Re: Sending ACK

Mirth sends the ACK back on the same socket that the incoming message came in on. It doesn't open a socket to the remote machine.

You can create an LLP destination that serves as an ACK for a channel...

[melcolm]

Re: Sending ACK

nshaik, your client app might not be accepting the ACK that Mirth is sending you. I noticed this with my client app...Mirth's ACK is not in a format that is compatible with my client app...time to edit the Mirth source

[chrisl]

Re: Sending ACK

Please let us know any adjustments that need to be made to accept the ACK so we can include it in a build!

Thanks,
-Chris

[pzelenka]

Re: Sending ACK

I appear to be running into the same ACK issue. I have Mirth up and running. I have a process that will send HL7 ADT messages originally from Meditech to a Mirth LLP Channel. The process successfully sends the first message in queue to Mirth and the message data is viewable in Mirth. The sending process errors the message due to "system not responding" and continues to attempt to a re-send of the same message. Send ACK is set to Yes.

nshaik: how was your issue resolved?

[nshaik]

Re: Sending ACK

Yes. I tested Mirth 1.4 using "LLP to File Writer" channel. Sent 142 ADT messages from the host. All 142 messages were received by Mirth and it sent an ACK back for each one of them. The HL7 host log showed all ACKs were received and processed successfully.

IMPORTANT NOTE: "Keep Connection Open" (in the Source tab) was set to "YES".

[pzelenka]

Re: Sending ACK

I have the Mirth 1.4 channel configured using the "LLP to File Writer" approach, too. The "Keep Connection Open" was not set to "YES". It is now and another testing cycle was initiated.

The Source Connector message arrived and is displayed in Mirth with the status of "TRANSFORMED". The Destination 1 message is also viewable in the Channel Messages in Mirth. It is cleaned up a bit compared with the Source message, with the START and END characters being removed. Two empty message segments, PV2 and UB2, are removed. I expect this is so because they don't contain any data. The template is ${message.rawData}.

The mapping for the Destination 1 message indicates that the "Message was routed successfully", but it is not in the C:/mirth.adt.txt file described in the Destination 1 File Writer Directory: and File Name: fields.

The sending system indicates that it still isn't getting an ACK from Mirth.

I have tried variations on the disabling and enabling the channel along with stopping and starting the channel in the dashboard. I presumed that things should be halted before changes and then restarted for them to take effect. Does Mirth require this when changes are made?

I created an export file on this channel for review. Does anyone know if there are any channel export files for various types of usage available for review online? I always find benefit in examples.

Thanks

[pzelenka]

Re: Sending ACK

After posting, I looked into the File Repository and found some examples to which I refered to above. Going to have to keep looking and testing.

[nshaik]

Re: Sending ACK

>>> I have tried variations on the disabling and enabling the channel along with stopping and starting the channel in the dashboard. I presumed that things should be halted before changes and then restarted for them to take effect. Does Mirth require this when changes are made?
<<<

After making changes to the channel, make sure Status is "Enabled" and select "Deploy All". This should make the changes to take effect.

=========================
Additional Info:

The host HL7 system I use is GE Centicity 2004 / Millbrook Integration Kit (MIK). This system requires ACK be sent back to the host IP on specified port number. This required "ACk on New Connection" to be set to "Yes" on the Source tab, Entered the IP Address, and ACK Port.

And on the Destinations tab, the settings were:
Directory: c:/test2
File Name: results${UUID}.txt
Append to file: No
File Type: ASCII
Encoding: Default
Template: ${message.rawData}
=========================

[pzelenka]

Re: Sending ACK

It turned out to be an access issue. The Mirth Service had the security setting of a Local System account and allowed to interact with desktop.
This was changed to an account with admin access. Once everything was stopped and restarted, the LLP to file interface worked as expected.

Thanks, again, Chris