// the find
tuva-health/tuva
Main repo including core data model, data marts, data quality tests, and terminology sets.
Tuva is a dbt package that transforms raw healthcare claims and clinical data into a standardized analytics data model. It targets healthcare data engineers and analysts who need to go from messy payer/EHR data to something they can actually query — handling ICD codes, DRGs, HCCs, quality measures, and more. If your org processes US medical claims and doesn't have a home-grown transformation layer, this replaces months of work.
The terminology and value set coverage is unusually complete — ICD-9/10, HCPCS, MS-DRG, CCSR, LOINC, NPI provider data, SNOMED — all versioned and published to S3/GCS/Azure Blob so you're not hand-managing CSV seeds. The CMS-HCC risk scoring mart is production-grade: it respects payment year configuration and follows the actual CMS model structure. CI runs full-refresh builds across six warehouses (Snowflake, BigQuery, Redshift, Databricks, Fabric, DuckDB) in separate GitHub Actions workflows, which is more disciplined than most dbt packages. DuckDB local dev with synthetic data means you can iterate without touching a real warehouse.
GitHub marks the primary language as JavaScript but the actual transformation logic is entirely SQL/dbt — the JS is just the DAG viewer UI, which is a misleading signal when evaluating the repo. The input layer schema is opinionated and narrow: you must map your source data to Tuva's exact field names and types before anything works, and the 'connectors' story for non-standard sources is thin (a few pre-built connectors, then DIY). FHIR preprocessing is off by default and clearly underbaked relative to the claims path — if your org is API-first rather than claims-first, you'll hit that ceiling fast. The seed artifact versioning across five separate databases (concept_library, terminology, value_sets, etc.) with independent version pins creates real upgrade coordination pain when one database ships a breaking change.