Onyx Blog
What Black Book’s Payer Interoperability KPIs Tell Health Plans About Making Clinical Data Work in Production
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. Onyx ranked #1 overall in the research, leading 11 of the 18 KPIs.
In Part 1, I looked at regulatory readiness, APIs, and standards execution. The challenge is not simply standing up compliant endpoints. Health plans need the services around them, including identity, consent, testing, monitoring, exception handling, and version management, so the infrastructure can continue to evolve as mandates and implementation guides change.
The next three KPIs move into what happens when that infrastructure meets real healthcare data:
Together, they ask a harder production question:
Can you make heterogeneous healthcare data trustworthy, reusable, and operational at scale?
A health plan’s clinical data environment rarely has one source or one exchange pattern.
Data may arrive from EHRs, HIEs, provider organizations, APIs, clinical documents, files, and ecosystem partners. The same member can appear across multiple systems with different identifiers. Clinical concepts can be represented differently across sources. Records can be incomplete, duplicated, inconsistent, or arrive at different times.
FHIR provides an important common structure for exchanging healthcare information, but a technically valid FHIR resource is not necessarily usable clinical data.
Production systems still have to answer questions such as:
This is where interoperability architecture and data architecture begin to converge.
If quality, risk adjustment, care management, and utilization management each solve these problems independently, a health plan can end up with multiple pipelines applying different matching logic, transformation rules, refresh schedules, and quality controls to the same underlying clinical information.
The objective should be to solve those common data problems at the platform level.
Black Book’s next KPI is Workflow Integration Across UM, Risk, Quality, and Care Management.
These are very different operational workflows, but they often depend on overlapping clinical information.
A quality workflow may need discrete clinical evidence. Risk adjustment may need relevant clinical documentation tied to a member and date of service. Care management needs a longitudinal view of the member. UM may need specific clinical information at a particular point in an authorization workflow.
The applications are different. Many of the underlying data problems are not.
That creates an important architectural decision: Does every application acquire, match, normalize, and prepare its own data, or can those capabilities be provided as reusable platform services?
The latter creates a very different model.
Acquire clinical information from the source. Resolve it to the correct member. Normalize it. Preserve provenance. Apply quality controls. Maintain a longitudinal record. Then make that common foundation available to the applications and workflows that need it.
The goal isn’t to force every use case into one application or data model. It is to stop making every application solve the same underlying data problems.
Provider activation can sound like an adoption or change-management metric. At payer scale, it is also an engineering problem.
Provider networks are heterogeneous. Organizations use different EHRs, configurations, endpoints, connectivity patterns, and authentication models. Their technical capabilities vary.
As the network grows, the infrastructure has to account for:
Prior authorization makes this particularly visible. CRD, DTR, and PAS define standardized interactions, but the production workflow still crosses payer systems, UM platforms, provider systems, EHRs, and other intermediaries.
A standards-compliant API that works with a handful of sophisticated participants is different from infrastructure that can support exchange reliably across a diverse provider network.
Provider activation therefore isn’t something to address after the architecture is built. It is one of the requirements the architecture needs to be built around.
This is where a significant amount of the engineering work behind payer interoperability actually happens.
The API may be the visible layer, but production reliability depends on what happens underneath it: acquiring information from heterogeneous sources, resolving identity, normalizing clinical data, preserving provenance, monitoring quality, managing exceptions, and making the resulting information consistently available to downstream systems.
That is also why we think about OnyxOS as a reusable data foundation rather than a collection of individual integrations.
The same core acquisition and data-management capabilities needed for regulated exchange can support other data-intensive workflows across quality, risk adjustment, care management, utilization management, and other payer priorities.
The engineering question we keep coming back to is: What capability can we solve once at the platform layer so every downstream application doesn’t have to solve it again?
The three Black Book KPIs in this part of the series provide a useful architecture check:
The answers can reveal an important distinction:
Have you built a collection of integrations, or a reusable clinical data foundation?
Part 1 of this series focused on building interoperability infrastructure that can adapt as regulatory requirements and standards evolve.
These next three KPIs expose what happens once that infrastructure reaches production.
The challenge is no longer simply moving the data. It’s making heterogeneous clinical information reliable, managing it consistently, and delivering it into real workflows without recreating the underlying data infrastructure every time.
Connect the ecosystem. Make the data trustworthy. Make it reusable.
That is how interoperability begins to move from a set of interfaces to durable healthcare data infrastructure.
Read Part 1: Building for Evolving Mandates
Explore the first four KPIs covering regulatory readiness, prior authorization, API coverage, and standards conformance.
Explore the full Black Book research
See all 18 KPIs and the comparative findings in Black Book’s 2026 payer interoperability research.
