Two questions decide whether an interface loses messages: what does the sender believe happened, and what does the engine do when a destination is unavailable? In Mirth Connect those are the source's response settings and the destinations' queue settings. Both are easy to leave at defaults and both deserve a deliberate choice per channel.
The acknowledgement is a promise
In HL7 v2 over MLLP, the sender transmits a message and waits for an ACK. The MSA-1 code tells it what happened:
- AA (application accept): the receiver has the message and will process it.
- AE (application error): the receiver got the message but could not process it.
- AR (application reject): the receiver refuses the message, often for a structural or routing problem.
Senders react differently. Many will resend on AE or AR, or stop the queue and wait for a human. Some do nothing. Before designing an interface, find out what the sending system does with each code, because that is what your ACK choice really controls.
When Mirth Connect sends the ACK
On the source connector, the response setting decides which response goes back and when. The main choices:
- Auto-generate before processing: the engine ACKs as soon as the message is received. Fast, and the sender is never held up by a slow destination, but an AA now only means "received". If processing fails later, the sender will not know.
- Auto-generate after the source transformer: the ACK reflects whether the message parsed and passed the source filter and transformer.
- Auto-generate after destinations complete: the ACK reflects whether the destinations succeeded. Accurate, but it ties the sender to the slowest destination.
- A specific destination's response: useful when the downstream system's own ACK should be passed back.
There is no universally right setting. A good rule:
- If the engine stores the message reliably and queues the destinations, acknowledge early. The engine has accepted responsibility, and holding the sender adds nothing.
- If the engine does not queue, or the sender must know whether the downstream system accepted the message, acknowledge after the destinations, and accept the latency.
What matters is that the promise in the ACK is true. An AA that means "received, and maybe lost later" is worse than a slow ACK.
Destination queueing
Each destination has a queue setting: never, on failure, or always.
- Never: a failed send errors the message for that destination. Someone has to notice and reprocess it.
- On failure: the engine tries to send; if it fails after the configured retries, the message goes to the destination's queue and is retried in the background.
- Always: every message goes through the queue first, decoupling the source from the destination entirely.
For any destination that talks to another system over the network, queue on failure or always is usually right. "Never" is appropriate when a failure should stop the line, for example a message that must not be delivered late.
Settings worth deciding explicitly:
- Retry count and interval before queueing, and the queue's own retry behaviour. Short intervals against a partner that is down for maintenance fill logs and can trip rate limits.
- Rotation: whether a failing message at the head of the queue blocks the rest. For order-sensitive streams like ADT, it should block, because sending A08 before the A01 it updates causes worse problems than a delay.
- Queue threads: more than one thread raises throughput but gives up ordering. Only use it where order genuinely does not matter.
Responses from the destination
When a destination sends to another HL7 system, it receives an ACK back. Decide what an AE or AR from the partner means for the message in your engine: should it error, queue for retry, or be accepted with an alert? Retrying an AR forever does not help. Rejections usually need a person.
A response transformer can inspect the partner's ACK and set the destination status accordingly, which keeps the engine's view of "sent" honest.
Make silence visible
The failure that hurts most is the one nobody sees. Alert on:
- errored messages per channel;
- queue depth above a threshold, and queues that have not drained in a set time;
- channels that have received nothing for longer than normal, which often means a sender has stopped, not that the day is quiet.
Route alerts to people who can act, and keep PHI out of alert emails.
A checklist per interface
- What does the sender do with AA, AE and AR?
- When does this channel acknowledge, and is that promise true?
- Which destinations queue, with what retry and rotation settings?
- What does a partner's AE or AR mean for the message?
- Which alerts fire, and who receives them?
We work through this list on every interface we build and every estate we support. It is short, and it prevents most of the lost-message incidents we are asked to investigate.
Chartferry is independent and is not affiliated with, endorsed by, or a reseller of NextGen Healthcare. Mirth Connect is a trademark of NextGen Healthcare, Inc.