offdataai
Healthcare & Life Sciences · data model template

Healthcare EDW data model

Data Vault 2.0 raw vault for healthcare: hubs (patient/encounter/provider/payer/facility), links among them, and satellites for demographics, encounter, provider, payer, and facility history plus a patient-payer coverage effectivity satellite. PHI is classified and masked.

Healthcare enterprise data warehouse as a Data Vault 2.0 raw vault: patient, encounter, provider, payer, and facility hubs; the relationships among them; and descriptive plus effectivity satellites — designed to consolidate patient data from many EHR, lab, and billing systems with full historization and the HIPAA auditability that makes Data Vault a strong fit for clinical EDWs. It is a Data Vault 2.0 raw vault: hubs for business keys, links for relationships and satellites for descriptive history, with hash keys and hash diffs generated in the DDL.

Data Vault 2.0Healthcare & Life SciencesHIPAAHITECHGDPR
16
tables
89
columns
14
relationships
7
PII columns

Opening the template creates a project with the ERD, platform-native DDL, a dbt project and documentation already generated (recommended platform: Databricks). Edit it in plain English or on the canvas, then ship it to any supported warehouse.

Subject areas

hubslinkssatellitesreference

Design decisions

  • Patient hub on the enterprise MRN / MPI

    Patient identity is consolidated from many systems; anchoring the patient hub on the master patient index lets every source attach its own satellite without reconciling identity downstream.

  • Encounter as its own hub

    An encounter is a first-class business object referenced by providers, facilities, diagnoses, and charges; modeling it as a hub keeps those relationships as independent links.

  • PHI isolated in satellites, masked

    Keeping demographics in a satellite (not the hub) limits PHI exposure and lets it be masked/classified phi for HIPAA while the hub stays a non-sensitive key.

Tables in the Healthcare EDW model

Every table with its grain, columns, types and keys. PK marks a primary key, BK a business key and PII a column classified as personal data, which gets a masking strategy by default.

Hubs (5)

hub_patient

Grain: one row per unique hub_patient business key

Patient by medical record number / enterprise master patient index.

ColumnTypeKeys
patient_mrnvarcharBK
load_datetimestamp
record_sourcevarchar

hub_encounter

Grain: one row per unique hub_encounter business key

ColumnTypeKeys
encounter_idvarcharBK
load_datetimestamp
record_sourcevarchar

hub_provider

Grain: one row per unique hub_provider business key

Provider by National Provider Identifier.

ColumnTypeKeys
npivarcharBK
load_datetimestamp
record_sourcevarchar

hub_payer

Grain: one row per unique hub_payer business key

ColumnTypeKeys
payer_idvarcharBK
load_datetimestamp
record_sourcevarchar

hub_facility

Grain: one row per unique hub_facility business key

ColumnTypeKeys
facility_idvarcharBK
load_datetimestamp
record_sourcevarchar

Links (4)

lnk_patient_encounter

Grain: one row per lnk_patient_encounter relationship

Encounters belonging to a patient.

ColumnTypeKeys
patient_hkbinary
encounter_hkbinary
load_datetimestamp
record_sourcevarchar

lnk_encounter_provider

Grain: one row per lnk_encounter_provider relationship

Providers participating in an encounter.

ColumnTypeKeys
encounter_hkbinary
provider_hkbinary
load_datetimestamp
record_sourcevarchar

lnk_encounter_facility

Grain: one row per lnk_encounter_facility relationship

Where an encounter took place.

ColumnTypeKeys
encounter_hkbinary
facility_hkbinary
load_datetimestamp
record_sourcevarchar

lnk_patient_payer

Grain: one row per lnk_patient_payer relationship

Patient insurance coverage relationship.

ColumnTypeKeys
patient_hkbinary
payer_hkbinary
load_datetimestamp
record_sourcevarchar

Satellites (6)

sat_patient_demographics

Grain: one row per patient_hk per change

Patient demographic history (PHI).

ColumnTypeKeys
patient_hkbinaryPK
load_datetimestampPK
first_namevarcharPII
last_namevarcharPII
date_of_birthdatePII
gendervarchar
ssnvarcharPII
address_line1varcharPII
cityvarchar
statevarchar
racevarchar
ethnicityvarchar
load_end_datetimestamp
record_sourcevarchar

sat_encounter_details

Grain: one row per encounter_hk per change

Encounter descriptive history.

ColumnTypeKeys
encounter_hkbinaryPK
load_datetimestampPK
encounter_typevarchar
admit_datedate
discharge_datedate
encounter_statusvarchar
drg_codevarchar
primary_diagnosis_codevarchar
load_end_datetimestamp
record_sourcevarchar

sat_provider_details

Grain: one row per provider_hk per change

Provider descriptive history.

ColumnTypeKeys
provider_hkbinaryPK
load_datetimestampPK
provider_namevarcharPII
specialtyvarchar
provider_typevarchar
network_statusvarchar
load_end_datetimestamp
record_sourcevarchar

sat_payer_details

Grain: one row per payer_hk per change

Payer descriptive history.

ColumnTypeKeys
payer_hkbinaryPK
load_datetimestampPK
payer_namevarchar
payer_typevarchar
load_end_datetimestamp
record_sourcevarchar

sat_facility_details

Grain: one row per facility_hk per change

Facility descriptive history.

ColumnTypeKeys
facility_hkbinaryPK
load_datetimestampPK
facility_namevarchar
facility_typevarchar
cityvarchar
statevarchar
load_end_datetimestamp
record_sourcevarchar

sat_patient_coverage

Grain: one row per coverage relationship per effectivity change

Effectivity satellite on the patient-payer link.

ColumnTypeKeys
patient_payer_hkbinaryPK
load_datetimestampPK
member_idvarcharPII
coverage_typevarchar
effective_fromdate
effective_todate
is_activeboolean
load_end_datetimestamp
record_sourcevarchar

Lookup tables (1)

ref_diagnosis

Grain: one row per ICD-10 diagnosis code

ColumnTypeKeys
icd10_codevarcharBK
diagnosis_descriptionvarchar
diagnosis_categoryvarchar

Relationships

Each relationship is a foreign key on the first table referencing the second.

  • lnk_patient_encounter.patient_hk → hub_patient (many-to-one)
  • lnk_patient_encounter.encounter_hk → hub_encounter (many-to-one)
  • lnk_encounter_provider.encounter_hk → hub_encounter (many-to-one)
  • lnk_encounter_provider.provider_hk → hub_provider (many-to-one)
  • lnk_encounter_facility.encounter_hk → hub_encounter (many-to-one)
  • lnk_encounter_facility.facility_hk → hub_facility (many-to-one)
  • lnk_patient_payer.patient_hk → hub_patient (many-to-one)
  • lnk_patient_payer.payer_hk → hub_payer (many-to-one)
  • sat_patient_demographics.patient_hk → hub_patient (many-to-one)
  • sat_encounter_details.encounter_hk → hub_encounter (many-to-one)
  • sat_provider_details.provider_hk → hub_provider (many-to-one)
  • sat_payer_details.payer_hk → hub_payer (many-to-one)
  • sat_facility_details.facility_hk → hub_facility (many-to-one)
  • sat_patient_coverage.patient_payer_hk → lnk_patient_payer (many-to-one)

Related templates

All templates →
Start for $1

From requirements to AI-ready context, in one platform.

Describe your business in a conversation, start from a template or connect your own database. Your first model is ready in minutes.

Get startedBook a demo

Plans from $1/month · cancel any time