01
Page now
Example: Silent ADT or results feed, all messages rejected, a subscription turned off
Approach: Paged to the on-call interface engineer, with the sending and receiving system owners notified.
Integrations / Interface Monitoring and Support
Healthcare Interface Monitoring and Support
The lab feed stopped at 2 a.m. and nobody knew until a clinician asked where the results were. Agnotic Technologies monitors and supports live HL7 v2, FHIR and X12 interfaces, so a quiet feed, a rejected message or a failed subscription reaches the right person first.
HL7 v2, FHIR and X12Silent feed alertsRunbooks per feedReplay without duplicates
Trusted by global innovators
What is healthcare interface monitoring?
Healthcare interface monitoring is the watch kept on live HL7 v2, FHIR and X12 feeds after go-live: message flow against each feed's normal pattern, acknowledgments and rejections, queue depth and failed deliveries. Agnotic Technologies sets it up, routes alerts to the right owner and fixes and replays failed messages safely.
Integration monitoring and support is a different job from building the interface. A feed can pass every test at go-live and still fail months later because a sending system was upgraded, a code table changed or a certificate expired.
This page covers what we watch and how we respond. Severity levels and service levels for a wider support contract are on our healthcare managed services page.
Signals per standard
Which signals should you monitor on each interface?
Each standard fails in its own way, so each needs its own signal and alert rule. These are the defaults we start from and tune per feed.
| Interface type | Signal to monitor | Alert rule | First runbook step |
|---|---|---|---|
| HL7 v2 over MLLP | MSA-1 acknowledgment codes: AE and AR from the receiver, or no ACK at all | Any AR, AE above the feed's normal rate, or ACK timeouts in a row | Read the MSA and ERR segments, then check the message against the receiver's spec |
| HL7 v2 over MLLP | Message count per feed against its hourly baseline | Volume below the expected floor for that hour and day | Check the sender's connection and queue before assuming no activity |
| FHIR REST | HTTP 4xx and 5xx responses, OperationOutcome issues, response time | Error rate above baseline, or any 401 or 403 after a token change | Check the OperationOutcome, then token scopes and expiry |
| FHIR R4 Subscriptions | Subscription status and the error element | Status moves to error or off | Read the error, test the endpoint, then reset the subscription |
| X12 batch | 999 rejections and 277CA claim acknowledgment rejections | Any rejected functional group, or 277CA rejects above baseline | Find the segment named in the 999 or the 277CA status, fix and resubmit |
| Any feed | Queue depth, retries and dead-letter count in the engine | Queue growing for longer than the agreed window | Check the downstream system, then pause the channel if needed |
Thresholds are set per feed from its own history, not one number for the whole engine.
Silent feeds
How do you catch a silent feed?
A silent feed is one that stops sending without raising an error. Nothing fails, so nothing alerts. It is the most common interface problem clinicians notice before IT does.
We catch it by learning each feed's own pattern: messages per hour by day of week, the gaps that are normal overnight or at weekends, and the event types that should always appear, such as admissions on an ADT feed.
An alert fires when volume falls below that feed's floor for the hour, not when it reaches zero. For low-volume feeds, a scheduled test message or heartbeat confirms the path is open.
Error queue and replay
How are failed messages fixed and replayed without duplicates?
Replaying a message twice can create a duplicate order or result. Every replay follows the same steps.
Quarantine
Failed messages go to an error queue with the reason, the original payload and the time, instead of retrying forever.
Triage by error class
Mapping errors, data errors, receiver outages and security failures each have their own owner and runbook.
Fix at the source
Mapping or code table fixes are made in the engine, and data errors go back to the sending system's team.
Check before replay
The receiver is checked for the message control ID or resource ID first, so anything already applied is not sent again.
Replay and confirm
The message is replayed, its acknowledgment or response is checked, and the item is closed with who did it and why.
Alert routing
Who gets which interface alert?
An alert that reaches everyone is read by no one. Routing is agreed per feed with the teams who own each end.
02
Ticket
Example: Rejection rate above baseline, a single failed message type, rising queue
Approach: Ticket opened in your service desk with the runbook link and sample messages attached.
03
Daily digest
Example: Isolated data errors returned to the sender
Approach: Listed for the sending team to correct at source, with counts by error type.
04
Monthly review
Example: Slow trends in volume, latency or error mix
Approach: Covered in the monthly interface report with any rule changes proposed.
Compliance as engineering
How is PHI handled in monitoring?
Interface engines hold full clinical messages. Monitoring must not copy them into more places.
Metadata first
Dashboards and alerts use counts, codes and control IDs, not message content.
Least privilege
Only named engineers can open payloads in the error queue, and each view is logged.
Regular log review
Access and replay logs are reviewed on a schedule as part of your security program.
BAA in place
Agnotic signs a business associate agreement before touching production interfaces.
Monthly report
What goes in the monthly interface report?
One report per month, per environment, written for the integration owner rather than the engine.
- Each feed's volume against its baseline, with gaps explained
- Rejections and errors by feed and error class
- Messages quarantined, fixed and replayed
- Alerts raised, who handled them and how long they stayed open
- Certificate, credential and endpoint changes due next month
- Upgrades planned by sending or receiving systems
- Threshold and runbook changes made, and why
Who it is for
Which teams use interface monitoring and support?
Anyone who owns a live feed and cannot afford to find out about a failure from its users.
Hospital integration teams
Engine feeds between the EHR, lab, radiology and pharmacy systems.
Health tech product companies
Customer-facing HL7 and FHIR interfaces run for many hospital clients.
Labs and imaging centers
Orders in and results out, where a silent feed delays patient care.
Payers and clearinghouses
X12 claim, eligibility and remittance batches with rejection tracking.
HIEs and networks
High-volume feeds from many senders, each with its own pattern.
Teams after an engine migration
New channels that need baselines before the old engine is switched off.
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Facts and sources
Which standards define interface failures?
Short facts behind the signal table, each linked to its primary source.
HL7 Version 2 acknowledgment codes, carried in the MSA segment, are AA (application accept), AE (application error) and AR (application reject), with CA, CE and CR used for enhanced-mode commit acknowledgments.
Source: HL7 Terminology, v2 table 0008 Acknowledgment CodeIn FHIR R4, a Subscription's status is requested, active, error when the server has an error executing the notification, or off when too many errors have occurred or the subscription has expired.
Source: HL7 FHIR R4, SubscriptionStatus value setThe X12 999 Implementation Acknowledgment reports the results of the syntactical and relational analysis of received X12 transaction sets; it does not cover the semantic meaning of their content.
Source: X12, Transaction Sets (999)The HIPAA Security Rule requires procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports.
Source: 45 CFR 164.308(a)(1)(ii)(D) (eCFR)
How we work
How does interface support start?
Three stages, starting with the feeds that matter most to patient care.
1.
Scoping call
We list your feeds, engines and owners and agree which ones are covered first.
Feed list
2.
Onboard the first feeds
Baselines, alert rules, routing and runbooks for those feeds, tested by simulating failures.
Fixed scope
3.
Run and report
Monitoring, triage, replay and the monthly report, with more feeds added on the same pattern.
Ongoing
Frequently Asked Questions
We work with the engines and integration platforms healthcare teams already run, including Mirth Connect, and with custom services. Monitoring reads the engine's own channel statistics and logs, so the approach does not depend on one product.
In HL7 v2, AE means the receiver found an application error in the message, and AR means it rejected the message, often for a reason such as an unsupported message type or a system problem. Both need action, but they go to different runbooks.
Yes. Alerts go to the paging, chat and service desk tools your teams already use. We add the interface rules and runbooks, not another console people have to watch.
Before replay, we check the receiving system for the message control ID or resource ID, and only replay what it has not applied. Every replay is logged with the engineer, the reason and the acknowledgment received.
It depends on the number of feeds and how much history exists for baselines. We agree the first set of feeds on the scoping call and onboard them before adding the rest.
Yes. Monitoring and runbooks for your most important feeds, often ADT and results, is a complete first scope, and the same rules extend to every other feed.
Engineers may use AI tools to draft runbooks and test scripts, and they review every one. AI tools never receive message payloads or PHI from your interfaces.