Integration does not fail loudly

When an application goes down, everyone knows within minutes. When an interface stops, it can be days. This asymmetry accounts for a large share of the operational damage that healthcare integration causes, and almost none of the attention it receives.

Why silence is the default failure mode

An interface is infrastructure that nobody looks at directly. Its output appears inside another system, attributed to that system. When results stop arriving, the first hypothesis is rarely "the interface has stopped" — it is that the order was not placed, or the specimen was not collected, or the other department is behind.

By the time the question reaches the integration team, the investigation has already consumed clinical time. And the trigger for that investigation was a person noticing an absence, which only happens when someone was actively waiting for a specific result.

An interface that fails without alerting is discovered by whoever needed it most urgently.

Upgrades are the common trigger

Interfaces rarely fail spontaneously. They fail when something upstream changes: a vendor upgrade, a new instrument, a configuration change in a system that seemed unrelated. A message that has been arriving in the same shape for three years arrives slightly differently, and a mapping that was never designed for that variation rejects it.

This is why interface inventory matters as much as interface quality. A great many organizations cannot produce a current list of which interfaces exist, what each one carries, and who owns it. Without that list, the impact assessment for a vendor upgrade is guesswork, and the rework is discovered after the change window rather than before it.

What monitoring should actually watch

Monitoring an interface engine's process health is not the same as monitoring message flow. The engine can be running perfectly while carrying nothing.

• Message volume against the expected pattern for that hour and day, so a drop to zero raises an alert on its own
• Rejection and error rates, trended rather than sampled
• Latency between send and acknowledgement
• Queue depth, which shows congestion before it becomes loss
• A defined owner and escalation path per interface, so an alert reaches someone who can act

The first item does most of the work. An interface that normally carries four hundred messages between eight and nine in the morning and carries none is in a detectable state, and detecting it takes an alert rule rather than a project.

Test against reality, not the specification

Integration testing performed only against the standard specification tests the case that was never going to fail. Real message traffic contains local conventions, optional segments used in non-optional ways, and fields populated differently by each contributing system. Capturing genuine message variation from the environment and testing against it finds the defects that the specification cannot.

None of this is sophisticated. It is inventory, alerting on absence, and testing against what actually flows. The reason it is so often missing is not difficulty — it is that interfaces are invisible until the moment they are extremely visible.