Onyx makes health data earn its keep

The health plan already had the records. Millions of them, arriving from contracted providers in the healthcare exchange format called FHIR. Yet, in a case study published by Onyx, the payer could not turn that abundance into dependable information. There were duplicates, incomplete records, and resources detached from the records they belonged to. The connection worked. The people downstream still lacked a usable picture.

That is a useful place to meet Onyx. Healthcare technology can make a successful transfer look like a finished job. Someone sends a record; someone receives it; a dashboard turns green. Onyx’s business lives in the troublesome distance between receipt and usefulness. Its current platform, OnyxOS, tries to make the same information serve several departments without each department having to reconstruct the patient.

A government apprenticeship

Onyx began with an unusually relevant apprenticeship. Its parent, NewWave, had worked on Medicare’s Blue Button 2.0, the service enabling beneficiaries to authorize applications to access their health information. In May 2020, NewWave launched Onyx to bring that experience to health plans. Susheel Ladwa became CEO, alongside strategy executive Aaron Seib and interoperability specialist Mark Scrimshire.

The first platform was called SAFHIR. Seib designed its concept; Scrimshire had helped architect Blue Button 2.0. Ladwa had led healthcare and life sciences cloud innovation work at IBM. This was a company assembled around a practical question: could knowledge acquired inside a federal data program become software other payers could operate?

Microsoft helped supply the commercial route. In July 2020, Onyx announced SAFHIR’s availability through Azure Marketplace and a co-selling arrangement with Microsoft. The company’s current platform materials describe joint development on Azure. The attraction for a buyer was straightforward: acquire healthcare-specific exchange technology with an established cloud foundation, rather than assemble every component internally.

The question after the connection

By February 2026, Ladwa was describing a different conversation with payer executives. They had connected their systems. They wanted to know what came next. In his account of the shift, clinical information still arrived in inconsistent fragments, lengthy documents, and scanned files. Quality teams and risk teams could end up building separate pipelines around the same member.

“The gap most payers face is not connectivity. It is usability.”

Susheel Ladwa · February 2026

Onyx’s January 2026 acquisition of InteropX fits that diagnosis. The acquired business brought clinical document interpretation, AI-assisted chart abstraction, and experience delivering large payer implementations. Onyx described the deal as a way to expand execution capacity and make interoperability useful across electronic prior authorization and other operations. The company was buying expertise in what happens after information arrives.

There is an important distinction here. OnyxOS already existed before the acquisition; InteropX expanded its capabilities and the company’s ambition. Read the deal as an extension of the product’s direction, rather than a sudden invention of the whole platform. The continuity matters because a health plan buys into a working data environment, with systems and staff already in place.

One record, several jobs

The architecture is easiest to understand from the bottom up. Onyx DataBridge acquires information from claims systems, electronic health records, exchanges, and APIs. It normalizes incoming material into a FHIR-native model. Above that sits infrastructure for regulatory exchange and a longitudinal record: the patient’s information connected over time. Applications then use that shared foundation.

Those applications address recognizable payer chores: measuring quality, finding gaps in documented care, supporting risk adjustment, and examining payment integrity. Onyx Compliance covers exchange functions including patient access, provider access, and payer-to-payer sharing. A member gets the benefit indirectly, through information available to an authorized app or a better-informed care workflow. The principal customer is the organization paying to run the infrastructure.

Onyx says its reach includes more than 50 payer organizations and 25 state Medicaid programs within its payer network. Its claim of more than 55 million supported lives describes members covered by those plans. It should be read as organizational reach, rather than a count of people actively using an Onyx consumer app.

The records were there. The usable record wasn’t.

Return to that overloaded payer. Onyx says it built an ingestion pipeline that resolved dependencies and removed duplicate resources, then organized the result for analytics with lineage tracking and access controls. A live quality dashboard sent feedback to data providers. The intervention addressed the point where incoming records became unreliable working material.

The published case study reports those improvements, but leaves the payer unnamed. Treat them as one vendor-reported engagement, rather than a forecast for every deployment. The useful lesson is more portable than the percentages: check dependencies, remove duplicates, preserve the record’s history, and give the sender feedback. Buying another connection would not, by itself, have fixed that problem.

The purchase includes the plumbing

Onyx sells software alongside implementation and expert services. Its public license puts custom work, schedules, and fees into negotiated statements of work. That makes the purchase a scoping exercise: which sources need connecting, which records need repair, and which teams must change their routines? Customers also carry responsibilities for their own infrastructure and access controls. The architecture depends on accurate patient matching and permission to use the incoming data. Teams also need to agree on the shared record. If each department continues keeping its own incompatible version, the promised reuse becomes much harder to realize.

Partners extend the offering. The 2025 Availity collaboration couples OnyxOS with provider network connectivity. Itiliti Health contributes prior authorization capabilities through a connector. These arrangements address a stubborn reality: an exchange platform needs reachable counterparties and a place in the actual workflow. Good software on one side of a disconnected relationship has limited value.

The market has alternatives, including 1upHealth, Smile Digital Health, and Edifecs. Onyx’s case rests on its standards expertise, delivery services, and shared data architecture. Its SAFHIR product won 2025 Best in KLAS for CMS Payer Interoperability, scoring 91.6. That recognition concerns a specific category, not every newer intelligence application. For a buyer, the sensible demonstration is to follow one record from arrival to a decision. The payoff depends on that entire journey working.