Onyx Blog
What Black Book’s Payer Interoperability KPIs Tell Health Plans About Reliability, Governance and Production Operations
Black Book’s 2026 payer interoperability research evaluates vendors across 18 key performance indicators. In this series, I’m looking at those KPIs in five practical areas through the lens of what it actually takes to build, operate and scale payer interoperability infrastructure.
In Part 1, Building for Evolving Mandates, I looked at the regulatory, API and standards foundation. In Part 2, Making Clinical Data Work in Production, I focused on what happens when that infrastructure meets real healthcare data: acquisition, normalization, workflow integration and provider activation.
The next four KPIs move us further into production:
These capabilities become increasingly important once interoperability is live. An API can pass conformance testing, a connection can work successfully in a sandbox, and an implementation can meet a regulatory deadline. But none of those things, by themselves, tell you how the environment will behave when thousands of users, applications, providers and systems begin interacting with it in production.
That is a different engineering problem.
As interoperability expands, so does the number of parties interacting with payer data. Members authorize applications. Providers request information. Payers exchange data with other payers. Applications need to be registered and authenticated. Consent and authorization have to be applied appropriately, and access needs to be traceable.
That creates a governance problem that cannot be solved with an API gateway alone.
Health plans need to be able to answer some basic questions consistently: Who is making the request? What organization or application do they represent? What are they authorized to access? Has the appropriate consent been established? What happened to the request? Can we reconstruct that activity later?
Those questions become more complicated as the number of endpoints and use cases grows. The architecture therefore needs services for identity, authentication and authorization, consent management, application registration, policy enforcement, logging and auditability. Just as importantly, those services should be reusable across interoperability workflows rather than implemented differently for every API.
This is particularly important as payer-to-payer exchange, provider access and prior authorization introduce different participants and authorization models into the same broader ecosystem. Governance cannot be something added after the data starts moving. It has to travel with the data.
Production interoperability is a distributed environment. A payer may be dependent on provider systems, EHRs, HIEs, utilization management platforms, third-party applications, identity services and other external endpoints it does not control.
Some of those systems will be unavailable. Requests will time out. Data will arrive late. Authentication will fail. Transactions will be incomplete. Standards implementations will vary.
The engineering question is not whether those failures will occur. It is whether the platform can identify, isolate and recover from them without turning every problem into a manual investigation.
That requires much more than uptime. Health plans need visibility into transaction volumes, latency, errors, failed connections and downstream dependencies. They need retry and exception handling, alerting, capacity management and operational dashboards that make it possible to understand what is happening across the environment.
As transaction volumes increase, the architecture also needs to scale without every new provider, application or workflow requiring another custom operational model.
At Onyx, this is an important distinction in how we think about production interoperability. The objective isn’t simply to make an API available. It is to create an environment where the health plan can see how that API — and the ecosystem behind it — is performing.
Regulatory programs naturally create deadlines. Deadlines are useful because they force decisions, testing and implementation, but they can also encourage teams to optimize for a date rather than for the operating environment that comes after it.
We see the difference when implementations move from controlled testing into production. Identity issues that appeared occasionally in testing become significant at volume. Differences between trading partners become visible. Data-quality exceptions accumulate. Operational ownership becomes important. Standards versions change. New participants have to be onboarded.
This is why implementation quality and time-to-compliance belong together.
Moving quickly matters, particularly as health plans work through overlapping CMS requirements. But speed has to come from reusable infrastructure, automation and repeatable implementation patterns — not from creating technical debt that has to be unwound after go-live.
A good implementation should make the next connection or regulatory requirement easier, not harder. That means treating testing, certification, configuration, monitoring and deployment as repeatable platform capabilities.
One of the less visible challenges in interoperability is deciding what happens when somebody needs help.
A developer may be unable to authenticate. A provider connection may fail. An application may pass testing but encounter a production issue. A payer-to-payer request may not match a member. A transaction may reach one system but not another.
The question in each case is the same: Who owns the problem?
In a distributed interoperability environment, the answer is rarely obvious. The issue may sit with the payer, the interoperability platform, an EHR, a utilization management vendor, an application developer or another ecosystem participant.
That makes support architecture almost as important as technical architecture. Health plans need defined ownership, escalation paths, documentation, monitoring and enough transaction-level visibility to determine where a problem actually occurred. Without that visibility, interoperability support quickly becomes a series of emails and tickets moving between organizations.
The better model is to make support part of the operating model: give teams the visibility, ownership and processes they need to identify the participant, transaction, failure point and next action.
Across these four KPIs, there is a common theme: much of the difficult work of interoperability sits behind the API.
Identity and consent services control access. Monitoring shows whether transactions are succeeding. Infrastructure has to handle growing volumes. Audit trails explain what happened. Testing and onboarding bring new participants into the ecosystem. And when something fails, operational tooling, processes and clear ownership help teams identify the problem and resolve it.
These shouldn’t be separate capabilities rebuilt for every new API or regulatory requirement. Within OnyxOS, we’re approaching them as shared platform services that can support multiple interoperability workflows.
That is the same architectural principle I’ve discussed throughout this series. If every new requirement creates its own identity model, monitoring process, support workflow and operational infrastructure, complexity compounds quickly. Build those capabilities into the platform once, and each new requirement becomes easier to operate and extend.
As interoperability programs move into production, health plans should look beyond whether an API is technically available and ask:
Those questions tell you much more about production readiness than a successful API test.
Once interoperability goes live, more participants connect, more data moves and more dependencies emerge. Standards change, volumes increase, and failures that were theoretical during design become operational issues that somebody has to diagnose and resolve.
That is why reliability, governance, implementation quality and support belong together. The objective isn’t simply to get APIs into production. It’s to create an environment that stays secure and observable, can recover when things fail, and can evolve without adding another layer of operational complexity every time something changes.
Production isn’t a milestone. It’s an operating model.
Get a clear view of where your organization stands today and what to prioritize as you prepare for the next wave of CMS mandates.
Download the 2026 Black Book Payer Interoperability Report to see the full 18-KPI framework and comparative vendor findings.
