The most dangerous interface failure is a quiet one

Standard infrastructure monitoring can show that every server is healthy while lab results have stopped reaching a ward. In an integration platform, the system being up does not prove the data is moving.

Watch the flow, not only the servers

• Queue depth: how many messages are waiting on each route.
• Message age: how long the oldest waiting message has been there.
• Acknowledgements: in HL7 v2, AA means accepted, AE an error and AR a rejection. Rising AE or AR counts often point to a change at one end.
• Silence: how long since a source last sent anything.

Alert on absence

Most alerts fire when something happens, so a feed that goes quiet may trigger nothing. Learn each interface's normal rhythm by hour and by day. A busy admissions feed that is silent for a few minutes at midday deserves attention, while the same gap overnight may be normal.

Plan for replay

Sooner or later, a destination will be down or a bad mapping will be deployed. Keep messages for a defined period so they can be sent again, in order, once the problem is fixed. Make sure the receiver can handle a repeat, and agree who has authority to start a replay.

Protect what the tools can see

Messages contain patient information, and monitoring tools tend to copy them into logs, screens and alert emails. Restrict who can view message content, audit that access, set retention limits and keep identifiable data out of alerts.

Write the runbook before the incident

For each critical interface, record who owns it at both ends, how to tell that it is failing, how to restart it safely and which clinical team must be told. The person on call at night should not have to work this out from the code. Clinical teams also need to know the downtime procedure, and when to return to normal working.