An interface that fails loudly is not the dangerous kind.

The RealityA feed that stops rarely announces itself

⚠️

The Problem

Failure is silent and discovery is clinical.

Nothing alarms. The first person to notice is a clinician looking for a result that should have arrived, and by then the gap is weeks wide.

🔧

The Solution

Watch the acknowledgement and the queue.

Alert on messages that stop being acknowledged and on a queue whose depth is growing, not on every individual error.

✅

The Resolution

Problems found in hours, not weeks.

A named person sees a real signal, the backlog is small enough to reprocess, and nobody reconstructs a month of results by hand.

The error queue nobody opens

Every interface produces failures. A message arrives for a patient who cannot be matched, an order that no longer exists, a code the receiving system does not recognise. Those messages are not lost — they are sitting in a queue.

In practices without a named owner, that queue is opened when somebody complains. We have seen queues holding months of traffic in organisations that considered the interface to be working, because in a narrow technical sense it was: it was running, accepting connections, and faithfully setting aside everything it could not file.

The fix is not technical. It is a name, a frequency, and an escalation path. Who opens the queue, how often, and what they do with something they cannot resolve. Write those three down before you tune a single alert threshold.

Message acknowledgement is the only real signal

HL7 messaging has a built-in receipt. The receiving system returns an acknowledgement saying it accepted the message, or rejected it, or encountered an error. That acknowledgement is the single most useful thing to monitor, and it is routinely ignored in favour of watching whether a port is open.

Two patterns are worth alerting on. Acknowledgements that turn negative — the far end is rejecting what you send, which usually means a mapping changed. And acknowledgements that stop arriving at all while messages continue to be sent, which looks healthy from the sending side and means nothing is landing.

A third, subtler one: acknowledgements still arriving but message volume dropping. A feed that normally carries four hundred results a day and carried six yesterday has not errored. It has quietly narrowed, and only a volume baseline will catch it.

Downtime, and the difference between silent and stopped

Planned downtime is straightforward: both sides know, messages queue, they reprocess on resumption. What needs designing is what happens when one side is down and the other does not know it.

Three questions decide how bad that gets. Does the sending system queue and retry, or discard? How long is the queue allowed to grow before it becomes its own problem? And when the connection returns, does everything reprocess in order, or does a backlog arrive out of sequence and file against the wrong encounters?

Answer those before an outage rather than during one. The recovery behaviour of an interface is rarely examined until the first real failure, which is the worst possible moment to discover that a day of results reprocessed in reverse order.

Alert fatigue: the failure mode of monitoring

The most common way interface monitoring fails is not that it was never built. It is that it was built to alert on everything, and within a fortnight everyone filtered it into a folder they do not read.

Alert on conditions that require a human decision, and report on everything else. A single message failing to match a patient is a queue item, not a page. A hundred failing in an hour is a page. A feed that has sent nothing since midnight is a page. A nightly summary of queue depth by interface is a report, and a good one.

The test we apply is simple: for each alert, name the person who will act on it and what they will do. If either answer is vague, it is a report. Getting this right is usually the largest single improvement available, and it costs nothing but judgement — and it is worth doing at the same time as rebuilding the workflow around the queue.

Audit controls and what the rule already requires

There is a compliance dimension here that is easy to overlook because interfaces feel like infrastructure rather than records.

The HIPAA Security Rule’s technical safeguards include audit controls to record and examine activity in systems that hold electronic protected health information, alongside integrity controls to prevent improper alteration or destruction and transmission security for data moving across a network. An interface engine does all three things by design, which puts it squarely in scope.

Worth reading alongside that: NIST’s cybersecurity resource guide for implementing the Security Rule, revision 2, published February 2024, which maps Security Rule standards to the Cybersecurity Framework and to SP 800-53 controls. It is the practical bridge between “implement audit controls” and knowing what that means on a Tuesday.

The standards picture around all this continues to move — the national interoperability programme has pushed toward a common exchange baseline — but the monitoring question does not change with the transport. Whatever carries the message, somebody has to know when it stopped.

What to put in place first

• Name the queue owner. A person, a frequency, an escalation path. Before any tooling.
• Alert on acknowledgement, not uptime. Negative, absent, or a volume drop against baseline.
• Decide recovery behaviour in advance. Queue, retry, order on resumption.
• Cut alerts to those a named person will act on. Everything else becomes a nightly report.

Qventive works as an HL7 interface alerting monitoring company for practices across New Jersey, and most engagements start by opening a queue nobody had opened. The work sits inside EHR Assist interface and, where the network and servers underneath need the same attention, managed IT support.

Because the engine holds and moves identifiable clinical data, it belongs in your HIPAA risk analysis, and the servers it runs on usually belong in a wider cybersecurity compliance review as well.

Interface monitoring: common questions