The Tuva Project Newsletter -- June 12 2026

We’re excited to announce that in a couple of weeks we’ll be releasing version 1.0 of the Tuva Project! After 133 releases, we felt like it was time.

1.0 represents a massive clean-up and simplification of the project based on feedback from dozens of our most die hard Tuva users and community members. We’re currently targeting early July for the release, and we’ll share more details soon about what you can expect.

In the meantime, if you have feedback you’d like to share or want to be an early tester of the 1.0 release, DM me in the Tuva Project Slack.

Now on to this week’s newsletter.

Lately I have been thinking a lot about data quality. I guess you can say I’m a glutton for punishment.

If you’re someone on the analytics side of things, whether healthcare or any industry, data quality is really inescapable — without it, you can’t trust any analysis.

In healthcare, we have almost no control over the data we analyze. Data is generated by clinicians talking or typing information into an EHR. From there, it’s turned into a bill, sent to a clearinghouse, passed on to a payer, run through an adjudication process, and spit out the other side into a data warehouse. We get access to this data — it’s called claims data. We also get access to data directly from the EHR, as well as data that flows from the EHR to networks called HIEs.

Ideally, we would fix data quality at the source, i.e. the data generation process, but in healthcare this is rarely possible. However, we can still analyze data quality and make a determination about how trustworthy it is.

So, how should we think about analyzing data quality? Ideally, you do this with a specific use case in mind.

But Tuva doesn’t support one use case — it supports a virtually unlimited number. Tuva transforms raw healthcare data sources, e.g. payer claims, EHR, HIE, etc., into a unified, enriched data model. Organizations use Tuva to aggregate all their disparate data sources into a common schema that serves as a foundation for analytics.

As a result, figuring out the right approach to data quality for Tuva became a difficult nut to crack. In fact, over the years we’ve had four different approaches to data quality in Tuva.

Those iterations, and frankly failures, led to our current framework, which we’re releasing with Tuva 1.0 in a couple of weeks.

The only way to approach a sufficiently complex problem like this is with a framework. Our framework for data quality at Tuva includes 3 different types of data quality: Structural, Logical, and Analytical.

Structural data quality checks the most basic things about the tables being mapped into Tuva — do they exist? are they populated? are the primary keys correct? are the data types correct?

This is the “do not pass go, do not collect $200” layer of data quality. If you have structural failures, you need to fix them before running Tuva. These are not subtle data quality issues that may or may not impact analytics downstream. These are showstoppers. If a table doesn’t exist, or is empty, or has the wrong grain, or has columns with the wrong data types, then Tuva can’t reliably transform that data. Everything downstream depends on these basic structural expectations being true.

Logical data quality checks whether things we expect about healthcare data are actually true. For example, every institutional claim should have one and only one bill type code, every ICD-10-CM diagnosis code should conform to a normalized value from terminology, every claim should have a patient, every service date should make sense, etc.

There are hundreds of these rules that we’ve programmed into Tuva. Users should run logical data quality checks before they run Tuva and try to fix as many errors as possible. Some errors can be fixed with mapping, but many errors will be inherent in your source data. You may not be able to do anything about these errors, but you should at least be aware that they exist because they can impact analytics.

This is an important distinction. Logical data quality issues are not always showstoppers in the same way structural issues are. Healthcare data is messy. If you wait until your data is perfect, you will never do any analytics. The goal here is not perfection. The goal is to understand where the data violates basic expectations so you can make an informed decision about whether the data is good enough for your use case.

Analytical data quality checks whether the core Tuva data model is ready for analytics. This looks at key metrics, trends those metrics over time to look for anomalies, and compares them to benchmarks from gold-standard datasets.

For example, after you run Tuva, you probably want to know things like: do PMPM costs look reasonable? do admission rates look reasonable? are professional and institutional claims showing up in the expected proportions? are there weird spikes or drops in utilization over time? does the data look complete for the time period you care about?

This is the layer that starts to answer the question everyone ultimately cares about: can I trust this data enough to use it?

The reason this framework matters is that it separates data quality into three different questions that often get lumped together:

1. Can Tuva actually run on this data?

2. Does the data follow the basic logic we expect from healthcare data?

3. And once Tuva runs, does the data look trustworthy enough for analytics?

Those are related questions, but they are not the same question. Structural, logical, and analytical data quality give us a simple way to think about each one separately. That simplicity is important because data quality can get overwhelming fast. Without a framework, you end up with hundreds or thousands of checks and no clear way to understand what they actually mean or if they even matter (see prior versions of data quality in Tuva for an example of this).

I should note that we aren’t directly analyzing source data quality with this approach. This is impossible to do in a programmatic way since every data source has its own schema. Instead, we analyze whether source data has been mapped into Tuva correctly, whether the resulting data follows the basic logic of healthcare data, and whether the final data model produces analytics that look reasonable.

This probably won’t be our last iteration on data quality. In fact, I’m almost certain it won’t be. But it does feel like the first version that gives us a real foundation to build on over time. It gives us a common language, a clear structure, and a much simpler way to help users understand whether their data is ready for analytics.

While this certainly isn’t a cure for cancer, it does feel like a fundamental improvement in the simplicity of how we assess data quality at Tuva, and I’m excited for you all to try it in action with the release of Tuva 1.0.

Here are some of this week’s job postings. Check out all the latest postings in the Tuva Slack #jobs channel.

• Morgan Health is hiring a Senior Associate of Analytics Engineering

• Hinge Health is hiring a Health Economist and Senior Health Economist

• Alliance Health is hiring a Medical Economics Analyst

• Cylinder Health is hiring a Data Engineering Manager

• CVS Health is hiring a Data Engineering Manager

• Centene is hiring a Senior Director of Clinical Data Science

Thanks for reading and if you’d like to receive more content like this in your inbox subscribe below.

To learn more about the Tuva Project visit www.thetuvaproject.com.