Mirth Connect Duplicate Messages: Why It Happens and How to Fix It

Mirth Connect duplicate messages usually show up as the same control ID appearing twice in the message browser, sent to the same destination within seconds or minutes of each other. Unlike most Mirth errors, this one rarely throws an exception — the channel appears to be working, it's just working twice.

Below is where the duplication actually originates, the fix for each source connector type, and how to catch it before a downstream system processes the same result twice. If duplicates are already reaching production, our free Mirth Health Check can trace the exact control ID back to its source — part of the Mirth Connect support work we do for US healthcare teams.

Duplication almost always starts at the source connector re-reading or re-sending something it already processed, not at the destination independently sending twice on its own. Each source connector type has its own way of tracking what's already been handled, and a gap in that tracking is what causes the repeat message to reach the destination a second time. Identifying which connector type is involved narrows the cause considerably before you look any further.

File Reader Not Moving or Deleting Processed Files

A File Reader left on its default After Processing Action of doing nothing will reprocess the same file on its next poll, since the file stays in the source directory. This is the most common cause of exact duplicates.

Missing or Delayed ACK Over MLLP

If a sending system doesn't receive its ACK within its own timeout window, many HL7 senders resend the original message, believing it was lost. Mirth then correctly processes what looks like a new message that is actually a resend.

Database Reader Re-Querying Already-Processed Rows

A Database Reader whose polling query doesn't exclude already-processed rows will pick up the same records on every poll interval. Without a status column or timestamp filter, there's nothing distinguishing new data from data already sent.

Source Connector Retrying After a False-Negative Timeout

A source connector can time out waiting for a downstream response even after the message was actually delivered successfully, and then retry the send. The message reaches its destination twice even though nothing was technically lost the first time.

The fix depends entirely on which source connector is involved, so confirm that first from the message browser's connector metadata rather than guessing based on the channel's general purpose. Each of the four causes above has a distinct fix, and applying the wrong one — tightening ACK timing on a File Reader issue, for instance — wastes time without stopping the duplication.

Set an After Processing Action on the File Reader

Configure the File Reader to move or delete files after successful processing, pointed at a separate archive directory rather than leaving files in place. This single setting resolves the majority of File Reader duplication cases immediately.

Confirm ACK Timing and Content for MLLP Channels

Check that the channel sends a valid ACK promptly and that the sending system's timeout window is long enough to receive it under normal processing load. A slow downstream step delaying the ACK is often the real root cause here.

Add a Processed Flag to the Source Query

Update the Database Reader's polling query to filter out rows already marked as processed, and add a follow-up update statement that sets that flag once the message is sent successfully. This closes the gap that causes repeat polling.

Add Control ID Deduplication in the Transformer

For source connectors where the above fixes aren't fully sufficient, a transformer step that checks the incoming control ID against a short-lived cache of recently processed IDs catches duplicates before they reach the destination, regardless of the underlying cause.

Preventing duplicates is mostly about making sure every source connector has an unambiguous way to know what it already handled, rather than relying on timing or assumptions about how fast a downstream step responds. A control ID cache adds a safety net across every connector type, but it works best alongside the connector-specific fixes above rather than as a substitute for them.

Log Every Control ID for a Rolling Window

Keeping a rolling log of processed control IDs, even a simple database table, gives you a way to both detect duplicates after the fact and build automated dedup logic going forward without redesigning the channel.

Tune ACK Timeout to Match Downstream Response Time

If your transformer or destination steps are slow, either speed them up or extend the sending system's ACK timeout expectation so a slow-but-successful send isn't mistaken for a failure and resent.

Test File Reader Config After Any Path Change

Any time a File Reader's source or archive directory changes, verify the After Processing Action still behaves as expected there. A moved directory with the wrong permissions can silently fail to move files even with the setting correctly configured.

Alert on Repeat Control IDs Within Minutes

An alert that fires when the same control ID appears twice within a short window catches duplication immediately, long before someone downstream notices a doubled record and has to trace it back manually.

If duplicates keep reaching production after the connector-specific fix, the underlying cause is often a combination — a slow ACK plus a File Reader edge case — that's hard to isolate from the log alone. Our free Mirth Connect health check traces the exact control ID back to its source connector as part of the standard diagnostic.

Book a Free Health Check →

Have an error accompanying the duplication? Send us the log, or check pricing for ongoing support plans.