Every healthcare data integration costs you twice

This post was written by Rachel Witalec, Chief Product Officer at Redox.

Go-live feels like it should be the finish line. Except, for the team running the integration, it’s really day one.

Most teams treat healthcare data integrations like a one-off project. Scope it, build it, test it, ship it, mark it done. Mapping the data, chasing the seventeen edge cases nobody mentioned at kickoff, testing, deploying. But it’s a known quantity. It has an end date, and you can staff against it. The cost is real, and most assume that it ends when the integration goes live.

However, there’s a second cost that has no end date, and nobody put it on the project plan. It begins the moment you go live and never stops. Someone has to watch traffic, catch failures, work out why something broke, and fix it. And it doesn’t scale. Your tenth connection doesn’t add 10% more monitoring work. It adds a whole new thing to watch, with its own quirks, its own partner on the other end, and its own very specific way of breaking at 2 am.

I know this because the Redox team currently maintains more than 15,000 live integrations every day (and growing). Our customers rely on us to monitor and maintain their integrations, and we take that responsibility very seriously.

If you’re not a Redox customer, this is where “let’s just build it ourselves” gets slippery. Building a connection to Epic or athenahealth is totally doable. You can put a number on it, staff it, and hit the date. But scoping what it takes to keep that connection healthy for the next five years is much harder.

The reality is that these aren’t really two costs. They’re two mental models. One categorizes interoperability as a project. The other categorizes it as infrastructure, something you never get to call finished, because you depend on it for as long as you depend on it. Once you see it that way, the question changes. It’s no longer “what does it cost to connect?” It’s “who’s going to run this, and how?” Increasingly, in today’s AI world where finding the signal through the massive amount of noise is even more important, there’s an emerging question of “how do we do it better?”

In a recent blog post where my colleagues Kalyn Gigot, SVP of Customer Success, and Andy Pung, SVP of Enterprise Sales dive into how to evaluate an interoperability partner, we called this the “Resource Tax.” That was a little different in that it was asking who would be responsible for maintenance and monitoring after go-live, not what it takes to run maintenance and how efficiently it works. Either way, here’s what it looks like up close, and why the smartest way to manage it is to catch problems before they’re worth catching.

Monitoring is the invisible job…until it isn’t

Once you’re live, one question matters more than any other. Is data actually moving the way it’s supposed to?

It sounds simple. But it isn’t, and the complexity compounds with every connection you add. Each one is its own stream of traffic, with its own definition of “normal” and its own new way to go sideways. Stack up dozens or hundreds of connections and you’ve now created a full-time job. Experienced teams and leaders know this. We certainly live this every day. The harder part for organizations who manage their own integrations is making the case for the headcount before the first incident makes it for you.

Figure 1. Example of the Redox User Dashboard. This is what a good answer to the question “is data moving the way it’s supposed to?” looks like.

Some breaks announce themselves politely. An endpoint goes down, an error fires, an alert pages someone, and everybody knows what to do. Those are the “easy” days because the issue is plain to see. The harder days are the ones where nothing looks broken. The issues are invisible. Traffic quietly spikes. A message type starts behaving a little differently. Data is technically flowing, just not where it should. A hospital recodes a field on their end, and three systems downstream start having a bad week without anyone telling you why.

Without visibility into what changed, you’re stuck doing forensics. A record didn’t arrive. A result never posted. Somebody files a ticket, and now you’re working backward from a symptom to a cause that could be weeks old.

That lag is the expensive part. Whether a field got recoded, or a cert expired, or a partner tweaked a message format and didn’t mention it; the defect shows up on day one, but the outage shows up on day thirty. By then you’re not just fixing the original problem. You’re reconstructing a month of drift in the middle of a live incident, which is much worse than catching it early would have been.

So, what can you do about it? Whether you are managing your own integrations or working with a partner, stop thinking of monitoring as simply finding out faster. The goal is finding out before it’s worth finding out about. A deviation caught on day two is a small, cheap fix. The same deviation left alone until day thirty (or more!) is an outage, which can disrupt clinical workflows, be expensive to unwind, or negatively impact a health system’s trust in you. Monitoring costs money. So does an outage. The difference is that monitoring is a cost for which you can budget. Outages show up whenever they want, and could cost you a customer account, three months’ worth of reimbursement, or even an interruption in patient care.

This isn’t just a cautionary tale. During the live webinar about Choosing the Right Interop Partner (now on-demand!), Kalyn told the story of a healthcare organization (NOT a Redox customer, to be clear) that went six weeks without sending a single result. The organization was working with an integration platform with no alerting or monitoring in place. No one noticed the lack of traffic until someone asked why billing had gone quiet, because in that workflow, no result meant no invoice. Six weeks of data silence, at a business doing close to a billion dollars a year, is not a rounding error. It is real revenue that has to be chased down after the fact.

One of the questions that keeps me up at night is, “How can we do monitoring better?” We have all these cutting edge AI tools and agentic capabilities now. There must be ways to use them to reduce latency, reveal the invisible, cut through the noise, investigate and remediate faster (or even without human intervention). This is a hypothesis my team is actively exploring.

Seeing the problem only helps if your team can act on it

Let’s assume we now all agree that monitoring matters. But visibility for its own sake is a hollow win if the only person who can actually do anything with it is your vendor.

Your vendor shouldn’t be the only one who knows what’s going on with your data. A good vendor’s job is to set your team up for success – able to see the issues, fix what they can, and hand off what they can’t. Your team should be able to do three things:

• Know what’s happening. Real traffic, real behavior, down to an individual log, not just a green checkmark on a status page
• Fix what they can. Get to the “why” themselves instead of opening a ticket and waiting
• Escalate what they can’t. Hand it over with the context already gathered, so it’s a fast, specific ask instead of “something seems off, IDK”

This matters even when (especially when) a service is fully managed. The less hands-on your team is day to day, the more that visibility is what earns trust. “Fully managed” shouldn’t be a nice way of saying “we’ll let you know if it breaks.” A black box run by someone else on your behalf is still a black box.

One of our sayings at Redox is “Do it yourself, but not by yourself.” Meaning that we aim to give our customers the self-service tools to do what they need to do, when they need to do it, but also, make sure that we provide guidance and all the benefits of our cumulative experience when it is helpful or needed.

TheAI-assisted tooling we’ve built into the Redox Engine platform, like one-click log summarization, is designed to do just that. It’s not a gimmick. It shortens the distance between “something happened” and “I understand why.” A single log can represent a processing path with nested transformations across multiple systems and a dozen-plus steps, the kind of thing that used to require an engineer to squint at a tree of JSON for twenty minutes to figure it out. Now it’s a plain-language explanation in a click, trained on years of real-world experience and wisdom. Your team can understand what happened right away instead of waiting for someone else to explain it.

Figure 2. Log inspector. Clicking “summarize” in the top right turns this into a sentence instead of a scavenger hunt.

Story time! Containing a network query surge

Here’s another real-world example that my team worked through recently. A data network serving senior- and long-term-care providers started returning errors on nearly every request it received, even though nothing had changed on its end.

The cause was upstream. A third-party member-locator service had a defect and began sending patient-lookup queries at a volume the network was never built to handle. Daily query volume jumped about 6x and held between 150 and 175 million queries a day for several days. To the receiving system, that looks like a flood.

Figure 3. Daily query volume during the surge period

Since Redox sits in the data path and watches traffic per connection and per organization identifier (OID), the pattern shift was visible as it happened. Those traffic views isolated the behavior, and rate limiting protected the destination while our platform absorbed a data flood an order of magnitude larger.

That cut the load reaching the destination from about 100,000 requests per minute to about 10,000, while Redox absorbed bursts of up to 450,000 per minute. It is worth noting that our platform absorbed this surge without flinching.

Figure 4. Rate limiting protection in action. On the left, volume before and after rate limiting was enabled. On the right, actual data volume during the anomaly period.

We shared the underlying data with the network operators so they could fix the root cause. Everyone was looking at the same view, which meant no one had to piece together what happened afterward. Volume receded once the issue was resolved.

Integrations will break. It is nearly impossible to predict when or how, but it will happen. This one stayed contained because the people responsible could see it early, reacted quickly, and worked together to resolve it. That’s the real value of monitoring. Not just knowing when something’s on fire, but seeing the smoke early enough to do something about it, together.

This is an incredible example of how we look out for and partner with our customers. If I were leading an in-house team and this type of anomaly occurred once every three years, I’d probably high five everyone and move on. But we manage situations like this regularly. We did give out quite a few high fives, but we are also challenging ourselves to figure out how to manage these situations more efficiently and effectively so we can be an even better partner to our customers.

Go-live is the beginning, not the finish line

The integration conversation has spent years obsessing over getting connected. How fast you can build, how many systems you can reach, how much engineering it takes, FHIR or HL7v2. That is all that mattered.

But getting data moving is only the beginning. Keeping it moving and making sure the team responsible isn’t waiting on someone else to tell them what’s going on is the invisible work that never ends.

So if you’re deciding whether to build this yourself orevaluating a vendor to do it with you, don’t stop your math at go-live. Who’s actually watching your data? How fast will they know something has changed? And when they need to know why, will your team be equipped to figure it out, or stuck in a queue?

If you already have a partner, the questions shift. How reliable is issue detection? Is the resolution process a partnership that inspires trust, or did you feel left in the dark the whole time? Does the incident drag on or get resolved quickly?

The real cost of an integration was never just what it takes to build it. It’s what it takes to keep it healthy for years without anyone having to think about it too hard. That’s worth designing for from day one. Interoperability isn’t a project with an end date. It’s a long-term investment in your team’s ability to run what they depend on.

So the next time someone tells you an integration is done, ask the only question that matters. Who’s watching it now?