The Tuva Project - An Open-Source Analytics Foundation

‍

US national health expenditures grew 7.2 percent to reach $5.3 trillion in 2024, or about $15,474 per person, accounting for 18 percent of GDP. That kind of spending pressure is exactly why payers and VBC organizations need leaner, more consistent data infrastructure. In this article, we'll go over what Tuva is, why it was built, and where it fits in a data roadmap.

‍

What Is the Tuva Project?

‍

The Tuva Project is an open-source data model built specifically for healthcare claims and clinical data. It exists to solve a problem almost every payer and VBC organization shares: nobody wants to keep rebuilding the same analytics infrastructure from scratch.

‍

The Business Problem Tuva Was Built to Solve

‍

Every health plan thinks its data problems are unique. In a lot of ways, they are not.

‍

Why health plans keep rebuilding the same analytical models

‍

When a health plan or VBC organization builds its analytics capability, a data team starts with raw claims. From there it writes SQL to clean the data, builds logic to flag chronic conditions, and builds more logic for cost and quality reporting. Meanwhile, a different health plan across the country is doing the exact same thing. Different team, different SQL, same problem.

‍

By the time Tuva Health's founders started the company, both had rebuilt essentially the same analytics platform multiple times. Each rebuild meant the same steps: ingest raw healthcare data, standardize, transform, validate, and turn it into something teams could use. That pattern has repeated across the industry for decades

‍

The fragmentation problem: claims data structured differently everywhere

‍

Claims data arrives as 837 procedure files, 835 remittance files, and 834 enrollment files, each with quirks depending on the sender. One organization defines a "chronic condition" one way, and another defines it differently. A third calculates cost per member per month through yet another logic path. Multiply that across dozens of vendors and reporting teams, and nobody is measuring healthcare the same way twice. It is like every city using its own definition of a mile. Distances technically get measured, but comparing results between cities becomes pointless.

‍

What fragmentation costs in time, budget, and consistency

‍

This fragmentation is genuinely expensive. The 2024 CAQH Index found a $20 billion savings opportunity if the industry shifted from manual to electronic administrative workflows. Routine administrative processes like eligibility verification already contribute to $90 billion in annual spending . The same report estimates 70 minutes saved per patient  visit under fully automated workflows.

‍

That same dynamic plays out inside data teams. Engineers burn months rebuilding logic that already exists elsewhere, analytics teams second-guess every number, and a departing engineer takes undocumented custom logic with them.

‍

The stakes around quality measurement are not small either. NCQA notes that more than 235 million people are enrolled in plans that report HEDIS results. That makes HEDIS one of health care's most widely used performance improvement tools. When that much of the population depends on consistent quality measurement, reusable logic stops being a nice-to-have.

‍

The History and Mission Behind Tuva Health

‍

Understanding where Tuva came from explains why it resonates so strongly with data teams.

‍

Why Tuva was founded and the insight behind it

‍

Tuva Health was founded in 2021 by Aaron Neiderhiser and Coco Zuloaga. Both are healthcare data veterans who spent over a decade solving the same problems at different organizations. They met in Salt Lake City in 2015 and discovered they were both working in healthcare data science. They eventually joined forces at Health Catalyst, then kept comparing notes on the same recurring frustration.

‍

Neiderhiser described how his time at Health Catalyst felt like reinventing the wheel on every aspect of healthcare data transformation. The team kept hitting the same ceiling, without proper tools to clean, normalize, and enrich data. That frustration became Tuva's founding premise: accelerating high-quality healthcare analytics for every organization in the industry. The premise rests on a belief that healthcare analytics should be open, accessible, and transparent.

‍

How Tuva Health Makes Money

‍

Tuva Health operates on an open-core business model, where the core software is free, open-source, and runs within the customer's own cloud environment. This community-driven approach serves as a distribution engine for building trust.

‍

Revenue is generated through value-added commercial services layered on top of this free foundation:

‍

• Managed Services - High-touch data factory services covering ingestion, quality testing, and enrichment.
• Enterprise Subscriptions - Fixed-fee annual licenses that include SLA-backed support, training, and advisory services.
• Professional Services - Implementation packages like the "Enterprise Starter Pack" to accelerate architecture and training.
• Marketplace Ecosystem - A revenue stream from a marketplace of certified third-party applications.

‍

By offering this model, Tuva helps organizations avoid the high costs of building proprietary data infrastructure in-house, serving a diverse client base of health plans, value-based care organizations, and digital health firms.

‍

The open-source approach: building in public

‍

What makes Tuva different from a typical vendor platform is that the core data model is open source. Anyone can inspect it, suggest changes, or build on it without a licensing fee. The platform launched out of stealth in late 2024 with five million dollars in seed funding. By that point it already had a community of 1,500 healthcare data and analytics practitioners contributing to and using the standard. That community angle matters. Instead of one vendor unilaterally defining chronic conditions, the logic gets scrutinized by people who work with this data every day.

‍

How Tuva fits alongside FHIR R4 and OMOP

‍

FHIR and Observational Medical Outcomes Partnership (OMOP) address distinct healthcare data needs. FHIR is the industry standard for exchanging clinical data between systems; as of 2022, 4 in 5 non-federal acute care hospitals now use APIs for this purpose. OMOP, conversely, standardizes clinical data specifically for population research.

‍

However, neither standard was built to help health plans transform raw claims into the analytics-ready data required for financial reporting and quality measurement. That is the gap the Tuva Project fills, serving as a functional complement to FHIR and OMOP rather than a direct competitor.

‍

Tuva as a common Gold-layer template

‍

Tuva is not a data warehouse or an application to install. It is a shared blueprint for how the analytics-ready layer of the architecture should be structured. The blueprint defines exactly how cleaned data should look before dashboards and risk models touch it.

‍

What Tuva produces

‍

Data Marts run automatically on top of the Core Data Model to create higher-level concepts for analytics, including:

‍

●      Measures for cost

●      Utilization

●      Quality

●      Outcomes

●      Groupers for service categories

●      Encounters

●      Chronic conditions

‍

The Chronic Conditions data mart implements two groupers, one defined by CMS and another defined by Tuva itself. Tuva built its own after finding gaps in the CMS logic, where certain conditions were missing or existing definitions were unsatisfactory. In plain terms, a diabetic patient gets flagged consistently no matter which report pulls that data.

‍

The role of dbt

‍

The Tuva Project is a dbt package for transforming raw healthcare data into analytics-ready data. Components include an Input Layer, Claims Preprocessing, Core Data Model, Data Marts, and Terminology and Value Sets. dbt lets data teams write transformation logic as version-controlled, testable code instead of scattered SQL scripts. For many healthcare organizations, data engineering still looks like it did in the early 2000s. Thousands of SQL files sit outside version control, orchestrated through stored procedures. Tuva is not a black box. It is code a data team can read, test, and extend inside its own warehouse.

‍

What source data Tuva expects

‍

CMS identifies 837 claims, 835 remittance, and 834 enrollment files as HIPAA-adopted electronic transaction standards forming the backbone of US payer data. On the clinical side, Tuva draws on ICD-10 codes and NPI hierarchies. The platform maps raw claims, EHR, ADT, and FHIR sources into a standardized input schema before the rest of the logic runs.

‍

Where Tuva Fits in a Modern Healthcare Data Architecture

‍

Knowing where Tuva sits in the architecture is what makes the concept click for a CIO.

‍

The Bronze, Silver, Gold medallion framework

‍

Most modern architectures follow a Bronze, Silver, Gold layering. Bronze is raw data, Silver is cleaned and validated data, and Gold is the curated layer ready for analytics. Tuva lives squarely in that Gold layer, assuming raw claims and clinical files have already landed in the warehouse. From there it transforms that data into the consistent structure downstream tools need.

‍

How Tuva connects to Microsoft Fabric and Databricks

‍

Tuva supports the major cloud data warehouses used by healthcare data teams, including Databricks, Google BigQuery, Amazon Redshift, and Microsoft Fabric. Every transformation stays inside the existing warehouse rather than requiring a separate system. Tuva does not require moving data anywhere new, which lowers both the cost and the risk of adoption.

‍

What sits on top of Tuva

‍

Once Tuva has done its work, the BI team builds on top of it. That means Power BI dashboards tracking cost and utilization, plus population health reports surfacing gaps in care. It also means quality pipelines feeding STARS reporting and financial models tracking medical loss ratio. Tuva does not replace these tools. It gives them a cleaner foundation.

‍

What Tuva Covers and What It Does Not

‍

No foundation, however well built, covers everything.

‍

Where Tuva creates the most analytical value

‍

Its Quality Measures data mart builds publicly available quality measure logic directly into the package. Separate data marts cover readmissions and AHRQ quality indicators. Chronic condition identification, cost and utilization reporting, and member attribution all benefit from one consistent definition instead of several competing ones.

‍

What Tuva does not replace

‍

Tuva does not replace the eligibility reconciliation process, CMS submission workflows, or RAF coding pipeline. Those carry payer-specific nuance and regulatory requirements a generalized open-source model cannot handle alone. Tuva gives an organization a clean analytics foundation. It does not file MOR or MMR files.

‍

The schema versioning consideration

‍

Tuva is community-maintained, which means it evolves: new condition logic gets added, and existing definitions get refined. That is a strength, but also a governance question. A team building production reporting on a specific version of Tuva's data marts needs a plan for updates. That plan should cover testing and rollout before changes reach live dashboards. A sensible practice is pinning the package version and running regression tests before adopting a new release.

‍

Why This Matters for Payers and VBC Organizations

‍

For regional health plans

‍

A regional health plan rarely has the engineering headcount of a national carrier. Every month spent on custom normalization logic is a month not spent on the analytics question leadership actually wants answered. A shared Gold-layer foundation lets a small team focus on what matters in its own market. Hundreds of other organizations have already built the same plumbing.

‍

For Medicare Advantage organizations

‍

STARS performance and risk adjustment accuracy are directly tied to revenue. CMS's 2026 Advance Notice fact sheet projected a net increase of 4.33 percent, or over $21 billion, in MA payments from 2025 to 2026. That projection sits alongside a continuing risk adjustment model phase-in. On quality, CMS's 2027 Medicare Advantage (MA) final rule notes MA-PD contracts are currently rated on up to 43 measures. MA-only contracts are rated on up to 33 measures. That much complexity rides on accurate data. Faster condition identification and quality logic give population health teams a real head start on gap closure.

‍

For value-based care organizations

‍

VBC organizations live and die by their ability to prove outcomes against contract benchmarks, and the program keeps growing. CMS's 2026 Shared Savings Program fast facts show 480 ACOs and 10.8 million assigned beneficiaries in 2024. Total earned shared savings reached $4.1 billion that year. A consistent Gold-layer structure means contract performance, cost tracking, and outcome measurement all draw from the same definitions. That makes it easier to demonstrate value and catch underperformance early.

‍

Evaluating Whether Tuva Belongs on the Data Roadmap

‍

Signs that Tuva is a strong fit

‍

Tuva deserves serious consideration at organizations standing up a new analytics layer or rebuilding an aging one. The same holds where engineers spend disproportionate time on custom normalization and departments pull inconsistent numbers from the same claims data.

‍

Signs that Tuva requires careful evaluation first

‍

Some conditions argue for a slower evaluation. Heavily customized Gold-layer logic already running smoothly, limited internal dbt expertise, or CMS submission pipelines tightly coupled to existing structures all qualify. None of these are dealbreakers, but they are reasons to pilot first. Tuva's public demo project loads a small synthetic claims dataset and runs the package end to end. That is a low-friction way to inspect the resulting schema before mapping real data to it.

‍

How Invene helps

‍

This is where a partner like Invene becomes valuable. Invene is a US-based data engineering and AI solutions firm working exclusively in healthcare. Invene helps health plans and VBC organizations evaluate whether Tuva is the right foundation, then implements it within Microsoft Fabric or Databricks. The team then builds the downstream pipelines connecting that foundation to STARS performance, RAF accuracy, and financial reporting.

‍

Final Thoughts

‍

The Tuva Project is a practical answer to a problem the healthcare data world has tolerated for too long. Everyone builds the same analytics infrastructure in isolation, even as national health spending climbs past $5.3 trillion a year. Tuva gives health plans, MA organizations, and VBC organizations a shared, open-source Gold-layer template. Data teams spend less time reinventing normalization logic and more time answering questions that matter. It is not a silver bullet, and it does not replace CMS submission workflows or payer-specific coding pipelines. But for organizations ready to standardize their analytics foundation, it is worth evaluating, ideally with a partner who has done it before.

‍

FAQs

‍

How can Invene help evaluate and implement the Tuva Project?

‍

Invene is a healthcare-exclusive data engineering and AI implementation firm. Invene helps payers and VBC organizations assess whether Tuva fits the current Gold-layer design. The team stands the package up inside Microsoft Fabric or an existing Databricks environment. It then connects Tuva to downstream STARS, risk adjustment, and financial reporting pipelines. Most engagements start with a 360 Analysis of the current data architecture before any implementation work begins.

‍

Is the Tuva Project free to use?

‍

Yes, the core Tuva data model is open source and free. It is delivered as a dbt package that runs inside the organization's own warehouse rather than as a paid license.

‍

Does Tuva replace our existing data warehouse?

‍

No, Tuva is a transformation layer that runs inside warehouses already in place, such as Microsoft Fabric or Databricks.

‍

Will adopting Tuva require us to rebuild our CMS submission processes?

‍

No, Tuva does not handle CMS submission workflows, RAF coding pipelines, or eligibility reconciliation. Those remain separate processes that Tuva works alongside.

‍

How much dbt expertise does our team need before adopting Tuva?

‍

Some working knowledge helps, since Tuva is delivered as a dbt package. Teams with limited expertise often start with a guided implementation or pilot.

‍

How does Tuva handle updates to its data model over time?

‍

Tuva evolves as its open-source community refines logic and adds capabilities. Organizations should pin package versions and plan a testing process before updates reach live dashboards.

‍

‍