This post was co-written by Kalyn Gigot, SVP of Customer Success, and Andy Pung, SVP of Enterprise Sales at Redox.
Let’s get the awkward part out of the way. One of us runs Sales and the other runs Customer Success, so yes, we have opinions about which interoperability partner you should choose. (Spoiler alert: we’re biased.)
We’ve spent a combined 20+ years selling and delivering interoperability. We’ve worked through thousands of evaluations, from the first discovery call to the latest renewal conversation. Our goal is to empower your team to think through the entire lifecycle of a solution. We’re sharing this advice to give you a broader lens as you evaluate what fits your unique needs.
This isn’t a comprehensive procurement checklist. You don’t need us to tell you to ask about security certifications or uptime SLAs. Instead, this guide is designed to highlight the non-obvious questions that may not come up during the initial sales cycle but will definitely come up later.
Think of this post as the home inspection before you buy. Every open house looks great. Fresh paint, staged furniture, cookies in the oven. Your job is to check the foundation, inspect the wiring, and understand what this place will actually cost you in the long run. Ask these questions of every solution you’re evaluating, including us. If the answers point somewhere else, buy the other house. Seriously.
If you already have an interop partner, these questions are equally important as you re-evaluate at each renewal. If you are already a Redox customer and your data needs are growing or changing, let’s dig into our approach to these questions and see if there’s more we should be doing together.
No matter where you fall on the interop partner/home buying spectrum, before the inspection starts, make sure you’re touring the right kind of property in the first place. Interoperability is plural, and vendors in this space are built for different jobs. For example, a network access platform that lets you query national networks for patient records is a great tool, the same way a condo is a great buy if you never want to touch a lawnmower. However, if your use case needs real-time event feeds from a specific health system, discrete write-back into their EHR, or scheduling workflows, you’re planning an addition, and a condo association won’t allow that. Neither category is wrong. The mistake is buying one when you actually need the other.
Let’s dig into three less obvious areas to inspect during your interop partner “property tours”: internal resources required for maintenance and monitoring, process for adding new integrations, and data usability upon delivery.
Uncover the internal “resource tax”
Most proposals are completely silent on how much of your own headcount it takes to keep their system running. When you’re evaluating solutions, you have to do the math on the real resource tax while fully understanding how that will impact your team’s capacity long term.
Ask: “What does the day-to-day maintenance and monitoring look like after go-live, and who performs it? What happens when standards evolve or a partner changes their system?”
Vendors sit somewhere on a spectrum. On one end, they fully own maintenance and monitoring. On the other, you get the toolkit, and your team owns the scripts, the monitoring, and the on-call responsibility that comes with it. Most vendors describe something in between, and “self-service” is the term that gets stretched the most to cover that middle ground.
Good self-service tooling means your team can see what’s happening (dig into an error, trace where a message stalled, confirm a connection is healthy) and often resolve it, without opening a ticket or waiting on a developer from either side. That’s meaningfully different from a dashboard that just shows you a status light with no way to act on it, or from “self-service” that really means your team is the one writing the monitoring and retry logic from scratch. The former shrinks your resource tax as you scale. The latter just relabels the toolkit.
Ask what it actually looks like day to day: who gets paged when something breaks at 2 am, what your team needs to know how to do to keep things running, and whether that responsibility shrinks or grows as you add more connections.
There’s no universally right amount of resource tax to carry. A team with deep in-house integration expertise might want more control and be glad to pay for it in headcount. A leaner team focused on other initiatives will happily pay to keep that tax low. The point is to know which tradeoff you’re signing up for before go-live, not after.
Tip: Ask if the platform is MCP-ready. As AI agents become standard operators within enterprise tech stacks, the way systems communicate is fundamentally shifting. Native support for Model Context Protocol (MCP) is quickly becoming the ultimate signal that a platform is built for what’s next, not just what’s now.
Understand what it looks like to scale
For homes, the foundation matters most when you want to add on. In interop, the same idea applies: the interop partner’s approach to adding integrations is the foundation that drives potential economies of scale. We’ll call this the “property tax” because the more you want to “own” (e.g. build yourself, specify a custom build), the higher the costs.
Ask: “What does the process look like when we need to add new integrations?”
What you’re trying to learn is how much of a typical new connection is reused versus started from scratch.
Good questions to get there: of the last ten connections built for customers like you, how many reused existing templates versus needing net-new development? If your next integration looks nothing like anything they’ve built before, what does that project actually involve? And where’s the line between what comes out of the box and what you’d need to spec or build yourselves?
One question that’s easy to skip but shouldn’t be: who is this vendor already plugged into, and is that connection reusable? If they already have an active connection into the specific health system or source you need, that’s a massive shortcut for your implementation team. When a connection already exists, things tend to move faster for a few concrete reasons.
- If they’ve already cleared that organization’s security review, nobody has to start that process from scratch.
- Reusing an existing VPN or cloud integration can shave weeks off a timeline.
- A configuration library tailored to that specific site means less time spent on custom specs and more time reusing what already works, while still leaving room to customize for what you need.
A vendor telling you that every connection is custom isn’t automatically a red flag. If you need bespoke configurability, have a dedicated team to spec and manage that work, and have the runway to do it, that might be the right fit. But if speed and low engineering overhead matter more to you, that same answer should give you pause, and existing connectivity is one of the fastest ways to tell which camp a given vendor actually falls into.
Tip: Ask how new connections are provisioned. Every new integration is a new door into your data, and what matters isn’t just how many doors you have, but whether each one can be shut down individually if something goes wrong, without taking every other connection down with it.
Moving data is not the same as delivering usable data
Here’s where the home inspection gets into the crawl space. Every vendor can move a message from point A to point B. The differences show up in what happens to that data once it arrives, and whether your team is left doing the messy work by hand: cleaning up codesets from multiple EHRs, chasing down more information to fill data gaps, figuring out how to get information back into the EHR, or manually triaging documents based on business logic to determine where it needs to go next.
There’s no universal checklist here. The right depth of capability depends entirely on what you’re trying to do. Here are three key areas worth digging into with any partner, regardless of your use case.
Enrichment and normalization. Reconciling varying codesets (like ICD-10, LOINC, RxNorm, and CPT) across different connected EHRs can cause massive delays before downstream data is usable. Look for partners who either provide or partner with a solution that absorbs this complexity rather than passing it to your team. Bonus points if they can also transform free text into structured data, since so much of healthcare data today is locked away in unstructured notes, faxes, and documents. Data gaps raise the same question. When something’s missing, does your team end up making phone calls and sending faxes to track it down, or can your interop partner automate that outreach for you?
Discrete writeback into source systems and EHRs. Reading data is one thing, but writing it back in a discrete, structured way is another. This matters most when you’re trying to drive real-time, interactive workflows, like ordering or scheduling, where the round trip back into the source system has to work. It also matters for organizations who need to stream real-time data into their cloud environment to generate insights, then funnel those insights back into the EHR at the point of care. If the writeback leg isn’t as solid as the ingestion leg, that insight never reaches the clinician when it matters.
Logic-based routing. Healthcare data doesn’t move in a straight line. Data might need to reach different destinations depending on its content, its source, or where it sits in a broader workflow. Partners who can apply logic to route data intelligently, rather than just deliver it from point A to point B, can unlock higher-value use cases like document triage for prior auth and referral routing. This is especially valuable for fax-based flows, which still dominate a lot of these processes today.
Tip: Ask your partner what tools they give you to actually see this happening. Enrichment, writeback, and routing logic all tend to be invisible by default, which makes troubleshooting painful when something breaks.
Before you sign anything
Any partner worth committing to will answer these directly. If they won’t, you have your answer, and you found it before closing instead of after moving in.
Ready to take your inspection further? We have two options for you First, we pulled the full question set from above into a final inspection checklist you can bring to vendor calls and RFPs, no form-fill required. Download it here.
Second, we’re hosting a live fireside chat on August 4th at 12:30ET where the two of us, moderated by our Chief Product Officer Rachel Witalec, will share what we’ve seen work and fail across thousands of integrations, and how to decode the answers vendors give you. Bring your hardest questions. Save your seat here.