The Dax Data Warehouse

The Dax Data Warehouse takes healthcare data as it actually arrives — claims from multiple payers, clinical records from multiple EHRs, enrollment files in whatever shape the source vendor produces — and turns it into one consistent, queryable model.

The problem it solves is not storage. It is that the same clinical fact arrives three different ways from three different systems: a diagnosis coded in ICD-10-CM on one claim and free text on another, a member identified by a payer member ID in one file and a patient MRN in another, an admission that appears as fourteen separate claim lines. Answering "how many inpatient admissions did this population have last year, and what did they cost?" requires all of that to be reconciled first. That reconciliation is what the warehouse does, and this site documents both the result and the reasoning.

What you can do with it

• Measure populations. Enrollment spans are exploded into member months, so every rate has a defensible denominator.
• Count episodes of care. Claim lines are grouped into encounters, so a hospital stay counts once rather than once per line.
• Analyse cost and utilization together. Both are summarised to the same member-month grain across the same service categories, so cost per encounter is a join, not a modelling project.
• See where the data is weak. A dedicated data quality layer flags missing fields, failed primary keys and structural mismatches per source.

How the documentation is organised

Section	What it covers
Getting started	Connecting, and the query patterns that avoid the common mistakes.
Warehouse layers	How raw source data becomes the core model, layer by layer.
Identifier naming	Schema, table and column naming rules.
Data dictionary	Every schema, table and column, generated from the model metadata.

The shape of the model

Data moves through five layers. Each one has a single job, and each writes to its own schema, so you can always tell how far through the pipeline a table sits.

source systems
      │
      ▼
dax_input_layer            source data mapped to a common shape
      │
      ▼
dax_normalized_layer       terminology and dates normalized
      │
      ▼
dax_claims_preprocessing   claims grouped into encounters, categorised
      │
      ▼
dax_core                   the analytics-ready model  ◄── query this
      │
      ▼
dax_data_quality           what is wrong with the data, per source

Most analytics should read from dax_core. The earlier layers are documented because you will eventually need them — to explain a surprising number, to debug a mapping, or to onboard a new source — but they are working material, not the query surface.

Where to go next

If you are about to write your first query, read Getting started. If you are onboarding a new data source or trying to understand why a value looks the way it does, read Warehouse layers. If you know the table you want, go straight to the data dictionary.