Identifier naming
The warehouse follows a small set of naming rules consistently. Knowing them means you can usually guess a column name correctly, and read an unfamiliar table without checking the dictionary.
Schemas
Every schema is prefixed dax_, followed by the layer:
dax_input_layer
dax_normalized_layer
dax_claims_preprocessing
dax_core
dax_data_quality
dax_intermediate
The prefix is uniform across the warehouse, so every schema moves together if it ever changes.
Tables
Table names are singular and describe one row: patient, encounter,
medical_claim. A table named patient holds one patient per row, not a
collection of patients.
Two prefixes mark tables that are not part of the query surface:
| Prefix | Meaning |
|---|---|
stg_ | Staging: a source table lightly shaped, nothing reconciled yet |
int_ | Intermediate: one step inside a larger transformation |
These are grouped under Internal models in the reference navigation. They are documented for lineage and debugging, and their shape can change between releases, so do not build reports on them.
Columns
| Pattern | Meaning | Example |
|---|---|---|
*_id | Identifier for an entity | person_id, encounter_id |
*_code | A coded value, as stored | hcpcs_code, drg_code |
*_description | Human-readable text for the adjacent code | drg_description |
*_date | A date, no time component | birth_date, claim_start_date |
*_datetime | A timestamp | result_datetime, ingest_datetime |
*_flag | Boolean-style indicator | death_flag, ed_flag |
*_amount | A monetary value | paid_amount, allowed_amount |
*_count | A count | claim_count, inpatient_count |
source_* | The value exactly as the source sent it | source_code |
normalized_* | The value after terminology normalization | normalized_code |
The source_ / normalized_ pairing is the one to internalise. Both are kept
so that normalization is never lossy: normalized_code is what you should
usually group by, and source_code is what you check when a normalized value
looks wrong.
Columns on every core table
| Column | Meaning |
|---|---|
data_source | Which contributing system the row came from |
dax_last_run | Timestamp of the build that produced the row |
ingest_datetime | When the source record was loaded into the input layer |
data_source is frequently part of the grain, not just an attribute. Check
the Grain row on a table's reference page and include every grain column in
your joins — see Getting started for what goes wrong
when you don't.
The dax_ namespace
Warehouse-level columns and variables sit in the dax_ namespace —
dax_last_run, dax_attributed_provider, dax_schema_prefix. These are
attributes the warehouse itself adds, as opposed to fields that came from a
source system, and the prefix is what tells the two apart when you are reading
an unfamiliar table.
:::note Names you can rely on These are the relations the warehouse actually exposes. The tables that serve them and the pages that document them are built from one shared definition, so what you read here is what you will find when you query. :::