By Karthikeya Rekulapalli, Data Architect, Midland Memorial Hospital
LinkedIn: Karthikeya Rekulapalli
An AI agent can find where a missing message failed before an integration engineer picks up the phone.
Diana called Jonathan from 3 West because the pharmacy was not receiving her unit’s supply scans.
Jonathan, a data engineer on our integration team, started checking interfaces in the integration engine. 3 hour later, he still had no answer.
He called Martin in infrastructure, who confirmed that the scanner had an active network connection. Diana unplugged the device and plugged it back in. Nothing changed. She switched to another scanner until the original was repaired.
The integration engine had never received a single message from the scanner. We had spent 3 hours investigating a message that never entered the integration layer.
The problem was not always in the middle
Another time, the failure was at the other end. An outside vendor was updating its SFTP server, and the endpoint became unavailable to our interface. Daily schedule files stopped reaching the team that depended on them. An email alert from a file-arrival monitor was the first sign.
In both incidents, the integration engine was healthy, but the message flow was not. Yet both started with a missing message report and a call to the integration team.
The integration team is asked to investigate first, even when the failure is elsewhere. The incident is only part of the cost. The rest is engineering time spent proving where it is not.
The first question
The first question is not “What’s broken?” It is:
Where did the message stop?
Source → Integration → Destination
If no message was ingested, the investigation moves upstream.
If the engine received the message but failed, the interface becomes the focus.
If processing succeeded but delivery failed, the investigation moves downstream.
That sounds simple, but across hundreds of interfaces, answering it repeatedly takes real engineering time.
Moving first-line triage to an AI agent
Today, an AI interface-triage agent sat at the front of that workflow. It reaches the integration engine’s management through the Model Context Protocol (MCP), which limits it to approved tools.
It retrieves:
- interface and connection status
- recent errors
- Meta data set on channel and last successful delivery
- message counts and timestamps
It then classifies the likely failure as source-side, integration-side, destination-side, or unknown, and explains it in plain words.
Staff do not know interface names. They know “3 West.” Team-reviewed, plain-English documentation of each interface lets the agent match the two.
The agent does not replace the integration engineer. It does the investigation that happens before the engineer can begin engineering.
Automation with boundaries
In healthcare, automation must be designed around control as much as capability.
The agent separates observation, diagnosis, and remediation.
Most interactions are read-only. Remediation is limited to actions such as restarting or redeploying a halted interface. Every action is logged, and nothing can be deleted. Anything else goes to an engineer, with the evidence already collected.
Data minimization by design
The agent does not need clinical message content for triage, so it does not receive it. It works on operational metadata such as status, error codes, timestamps, and connection state. PHI-containing payloads are excluded from its context.
The question it needs to answer is not:
“What does this patient’s message say?”
It is:
“Did this interface receive a message, process it, and deliver it?”
The scalability question
The value is clearer when hundreds of reports arrive at once. In July 2024, a faulty CrowdStrike security update disrupted about 8.5 million Windows devices worldwide, by Microsoft’s estimate. In a hospital, that means dead workstations while IT also hears that messages are not moving.
An integration team cannot check every interface at once. An agent can, show which interfaces are still processing and which are failing. That defines the incident’s boundaries faster.
Faster support is a side effect. The real goal is saving scarce engineering expertise for the failures that need it.
What changes for the engineer
Restarting an interface is the least interesting thing the agent does. What matters more is that an engineer no longer spends the first part of every investigation proving the integration layer is innocent.
The engineer still handles ambiguity, complex failures, remediation, and accountability. The AI handles the first question.
Where did the message stop?
If Diana called today, the answer might come back in minutes:
The integration engine has not received a message from your scanner.
That does not fix the scanner. But now, Jonathan can understand see through things.
That may be a more useful definition of AI in healthcare operations: better information for the people who understand the infrastructure, before they must act.