Creating a Payer-Provider Analytics Portal to Accelerate Value-Based Care Adoption

Context

Inovalon operated an analytics platform called INDICES that helped health plan clients understand how their programs were performing. It was an internal-facing tool: payer organizations used it to track quality measures, risk scores, and compliance data across their member and provider populations. It had never been designed for, or exposed to, providers.

The client was a top 5 U.S. health insurer with a multi-state presence and a provider network of over 300,000. They were facing a strategic challenge that no amount of internal analytics could solve on its own: their provider network was resistant to adopting value-based care (VBC) payment arrangements.

The Real Problem

I was brought into a meeting with the client as a business intelligence expert. The client presented the problem as a need for dashboards: they wanted to show providers their quality and risk metrics so that providers would understand the value-based care opportunity.

But as I listened to the client describe provider resistance, I recognized that dashboards alone wouldn't solve the underlying problem. Providers weren't resisting VBC because they lacked data. They were resisting because they were afraid.

I pushed back on the client's initial request. Building dashboards to show providers their metrics would address the visibility problem, but it would leave the deeper issues of operational burden, data accuracy, and trust untouched. I advocated for doing field research before committing to a solution, to understand what providers actually needed in order to feel confident adopting VBC.

The Opportunity I Saw

What made this project unusual was the product insight underneath it. INDICES had never been used as a provider-facing tool. Extending it to serve providers would essentially create a multi-sided marketplace connecting four stakeholders: Inovalon (the technology platform), the payer (the health plan client), the provider (the end-user), and the patient (whose health outcomes everyone was trying to improve). This was a novel use of existing technology that required rethinking everything from the underlying data architecture to identity and access management to the licensing agreement with our analytics vendor, since we were effectively reselling the product in a new way.

The client had a hypothesis: if they offered providers bridge contracts with only upside potential and no downside risk, and if they partnered with us to build a product giving providers real visibility and proactive tools for managing VBC performance, providers would grow comfortable enough to expand their contracts and accept standard risk arrangements. I made the case internally to scope, fund, and staff the project. I secured a dedicated scrum development team and began the work of turning this hypothesis into a product.

My Role

I owned this initiative end-to-end. I worked directly with the client to understand the problem. I went into the field and met with providers to understand their pain points and needs. I scoped the project and secured funding and a development team. I managed the entire development cycle, presenting every new feature to the client and collaborating on prioritization. I partnered with our data team on data specifications and the ingestion of non-standard provider data files. I managed the beta rollout, conducted additional fieldwork to observe providers using the product, and ran the feedback cycle of fixes and enhancements. I planned and executed the full-scale rollout state by state, including training materials and state-specific branding.

I was doing design thinking intuitively throughout this process, before I had been formally trained in it. I wanted to make sure we were solving the right problem to de-risk the launch. The team members I had hired to help me with the user interface (since I'd never worked on a UI before) ended up teaching me the foundations of design thinking and encouraging the instinct to go into the field, observe users in context, push back on the stated requirements, and validate the solution with real users before scaling it. Over the next 3 years, I would pursue the discipline more deeply through formal training and learn how to name the skills I was using and structure repeatable templates for other product leaders to replicate my positive results.

The Approach

Field Research

I traveled to provider offices across the client's service area to observe how provider group staff actually managed their quality programs. Rather than interviewing executives or administrators, I sat with the people who did the daily work: population health coordinators, clinical support staff, and office managers.

The field research revealed several findings that redirected the product strategy:

The Data Quality Discovery

One of the most valuable outcomes of the research was unintentional. When we began building the provider-facing UI and presenting the data in a clean, readable format, it exposed data quality issues that had been invisible when the data lived only in internal analytics tools. Missing records, inaccurate patient matching, outdated compliance statuses: all of these became visible when a provider looked at the screen and said "that's not right."

This triggered parallel workstreams on the client side to clean up their data, and we had to build features that allowed providers to flag and report inaccuracies. The product became a data quality mechanism as well as an analytics tool, which strengthened the client relationship and increased provider trust in the system over time.

Design and Development

I structured the solution around the findings from field research, organizing features into short, medium, and long-term horizons:

The product was designed as a white-label solution branded entirely under the client's identity. Each state's deployment required state-specific branding and logos for different lines of business, all of which needed approval from the client's marketing and legal teams. This added complexity but was essential: providers needed to see the tool as coming from their health plan partner, not from a technology vendor they'd never heard of.

Securing the Technical Foundation

Extending the platform to external provider users required foundational infrastructure changes that went well beyond the UI. I worked with engineering to implement centralized identity and access management with SSO and multi-factor authentication, which was critical for a product handling protected health information. The analytics vendor licensing had to be restructured for the new use case. The underlying database architecture needed modification to support provider-level access controls and data segmentation.

Beta and Rollout

The rollout followed a deliberate progression:

Results

What I Would Do Differently

I would formalize the research methodology earlier. I was practicing design thinking instinctively throughout this project: doing field research, building personas from observation, testing solutions with real users, and iterating based on feedback. But because I didn't have a structured methodology at the time, I wasn't documenting findings as systematically as I later learned to do. Formal research synthesis would have made the insights more shareable and the case for design investment more concrete.

I would also invest earlier in the data quality infrastructure. We discovered the data accuracy problem organically through the UI work, which was valuable, but building data validation and provider feedback tools into the initial scope rather than as a reactive addition would have shortened the trust-building cycle with providers.

Finally, I would establish baseline metrics more rigorously at the outset. We knew the product was driving VBC adoption and improving provider engagement, but without formal baselines on provider workflow efficiency, gap closure rates, or satisfaction scores, the impact story relies on scale (14,000+ users) rather than depth. Having before-and-after metrics would have made this a more complete case study.