Databricks for Healthcare Data
A practical guide for healthcare data engineers and architects building on Databricks — Unity Catalog PHI governance, Delta Lake for claims and clinical data, medallion architecture patterns, HIPAA compliance, and dbt integration for healthcare analytics at scale.
Why Databricks for Healthcare?
Databricks has become a leading platform for healthcare data engineering teams building large-scale data pipelines, machine learning models, and unified analytics platforms. Its combination of Apache Spark for distributed processing, Delta Lake for reliable ACID transactions on cloud storage, and Unity Catalog for centralized governance makes it particularly well-suited for the complex, high-volume data workloads healthcare organizations face.
Healthcare data volumes are growing faster than most industries — a single large health plan processes millions of claims monthly, EHR systems generate continuous streams of clinical events, and value-based care programs require population-level analytics across billions of longitudinal patient records. Databricks Spark-based architecture scales horizontally to handle these workloads in ways that traditional SQL-only platforms struggle with.
This guide covers the practical decisions healthcare data engineers face when building on Databricks — from HIPAA configuration and Unity Catalog PHI governance to Delta Lake optimization, medallion architecture implementation, and dbt integration patterns.
Databricks Healthcare Architecture Overview
Unity Catalog
Governance layer — PHI access control and lineageCentralized metastore providing fine-grained access control, column masking, row filtering, data lineage, and audit logging across all Databricks workspaces. Unity Catalog is the primary mechanism for enforcing HIPAA minimum necessary access requirements and maintaining PHI audit trails in Databricks healthcare platforms.
Delta Lake
Storage layer — ACID transactions on cloud object storageOpen-source storage format providing ACID transactions, schema enforcement, time travel, and Z-ordering optimization on top of cloud object storage (S3, ADLS, GCS). Delta Lake is the storage foundation for all healthcare data layers — raw EDI files, standardized clinical records, and dimensional analytics marts.
Structured Streaming
Ingestion layer — real-time healthcare event processingSpark Structured Streaming enables continuous ingestion of HL7 ADT messages, claims status events, lab result feeds, and patient monitoring data into Delta Lake tables with exactly-once processing guarantees, enabling near-real-time analytics on continuously updated healthcare data.
Databricks SQL
Query layer — analyst-facing SQL and BI servingServerless or pro SQL warehouses providing high-performance SQL query execution against Delta Lake tables for analyst-facing queries, BI tool connections (Tableau, Power BI, Looker), and dbt model execution. Databricks SQL enables SQL-first analysts to query the same Delta Lake tables that data engineers build without requiring Spark knowledge.
MLflow
ML layer — healthcare predictive model lifecycle managementIntegrated ML experiment tracking, model registry, and deployment platform for healthcare machine learning workflows including readmission risk models, disease progression prediction, medication adherence scoring, and population health risk stratification models used in value-based care programs.
Unity Catalog — PHI Governance for Healthcare
Unity Catalog is the cornerstone of HIPAA-compliant data governance on Databricks. Here is the recommended three-level namespace structure and PHI security configuration for healthcare platforms.
-- Unity Catalog namespace setup for healthcare -- Three-level: catalog.schema.table -- Catalogs by data sensitivity and lifecycle stage CREATE CATALOG raw_catalog COMMENT 'Source-aligned raw ingested data — PHI present'; CREATE CATALOG staging_catalog COMMENT 'Cleaned validated data — PHI present'; CREATE CATALOG marts_catalog COMMENT 'Analytics-ready dimensional models — PHI controlled'; CREATE CATALOG reference_catalog COMMENT 'ICD-10, NPI, taxonomy reference data — no PHI'; -- Schemas by domain within each catalog CREATE SCHEMA staging_catalog.claims; CREATE SCHEMA staging_catalog.member; CREATE SCHEMA staging_catalog.clinical; CREATE SCHEMA staging_catalog.pharmacy; CREATE SCHEMA marts_catalog.claims; CREATE SCHEMA marts_catalog.member; CREATE SCHEMA marts_catalog.quality; CREATE SCHEMA marts_catalog.finance; -- Grant schema-level privileges GRANT USE SCHEMA ON staging_catalog.claims TO `data-engineer-group`; GRANT SELECT ON staging_catalog.claims TO `phi-analyst-group`; -- Restrict marts to appropriate roles GRANT SELECT ON marts_catalog.claims TO `claims-analyst-group`; GRANT SELECT ON marts_catalog.quality TO `quality-analyst-group`;
Column Masking for PHI Fields
-- Create column masking function for member names
CREATE OR REPLACE FUNCTION
marts_catalog.security.phi_name_mask(col STRING)
RETURN CASE
WHEN is_member('phi-analyst-group') THEN col
WHEN is_member('claims-analyst-group') THEN '***MASKED***'
ELSE NULL
END;
-- Apply to PHI columns in member dimension
ALTER TABLE marts_catalog.member.dim_member
ALTER COLUMN mbr_first_nm
SET MASK marts_catalog.security.phi_name_mask;
ALTER TABLE marts_catalog.member.dim_member
ALTER COLUMN mbr_last_nm
SET MASK marts_catalog.security.phi_name_mask;
-- Date masking for patients over 89 (HIPAA de-id)
CREATE OR REPLACE FUNCTION
marts_catalog.security.phi_dob_mask(dob DATE)
RETURN CASE
WHEN is_member('phi-analyst-group') THEN dob
ELSE DATE_TRUNC('YEAR', dob) -- show year only
END;
ALTER TABLE marts_catalog.member.dim_member
ALTER COLUMN mbr_dob
SET MASK marts_catalog.security.phi_dob_mask;Row Filters for Population-Level Access
-- Row filter: analysts see only their authorized populations
CREATE OR REPLACE FUNCTION
marts_catalog.security.member_population_filter(
plan_cd STRING, mbr_state_cd STRING)
RETURN
is_member('phi-analyst-group')
OR is_member('data-engineer-group')
OR EXISTS (
SELECT 1
FROM marts_catalog.security.user_population_access
WHERE user_group = current_user()
AND (allowed_plan = plan_cd OR allowed_plan = 'ALL')
AND (allowed_state = mbr_state_cd OR allowed_state = 'ALL')
);
-- Apply row filter to member dimension
ALTER TABLE marts_catalog.member.dim_member
SET ROW FILTER
marts_catalog.security.member_population_filter
ON (plan_cd, mbr_state_cd);Medallion Architecture for Healthcare Data
The medallion architecture — bronze, silver, gold — is the standard data organization pattern for Databricks healthcare platforms, providing progressive data quality refinement with clear layer boundaries.
Raw ingested data
Raw EDI 837 files, HL7 ADT messages, EHR extracts, eligibility flat files
Immutable — never modify bronze data. Add received_ts metadata only.
Cleaned and validated
Typed columns, ISO-11179 names, ICD-10 validated, NPI format checked, duplicates removed
One silver table per source table. Apply dbt tests here.
Business-level marts
fact_claim_header, dim_member (SCD2), fct_hedis_cbp, fct_member_months
Dimensional model. Apply Unity Catalog row filters and column masks here.
-- Bronze layer: raw EDI 837 ingestion CREATE TABLE raw_catalog.claims.edi_837_raw ( raw_id STRING NOT NULL, interchange_ctrl STRING, claim_type STRING, -- P, I, D raw_content STRING, -- full EDI file text source_system STRING, received_ts TIMESTAMP NOT NULL DEFAULT current_timestamp(), processed_flg BOOLEAN NOT NULL DEFAULT FALSE ) USING DELTA LOCATION 'abfss://bronze@healthlake.dfs.core.windows.net/claims/edi_837_raw' TBLPROPERTIES ( 'delta.enableChangeDataFeed' = 'true' ); -- Silver layer: standardized claims header CREATE TABLE staging_catalog.claims.stg_claims_header ( clm_nbr STRING NOT NULL, mbr_id STRING NOT NULL, billng_prvdr_npi STRING, rndrng_prvdr_npi STRING, payer_id STRING, svc_dt_from DATE, svc_dt_to DATE, prim_diag_cd STRING, -- VARCHAR(7) icd_vrsn STRING, -- ICD9 or ICD10 bld_amt DECIMAL(12,2), paid_amt DECIMAL(12,2), clm_sts_cd STRING, rec_creat_ts TIMESTAMP, rec_updt_ts TIMESTAMP ) USING DELTA LOCATION 'abfss://silver@healthlake.dfs.core.windows.net/claims/header' TBLPROPERTIES ( 'delta.enableChangeDataFeed' = 'true', 'delta.autoOptimize.optimizeWrite' = 'true', 'delta.autoOptimize.autoCompact' = 'true' );
Delta Lake Optimization for Healthcare Workloads
Z-Ordering for Claims Analytics
Co-locate related data for fast time-bounded claims queries
-- Optimize claims fact table with Z-ordering -- Run after large data loads or weekly OPTIMIZE marts_catalog.claims.fact_claim_header ZORDER BY (svc_dt_from, payer_id); -- Liquid clustering (Databricks Runtime 13.3+) -- Better than Z-ORDER for frequently updated tables ALTER TABLE marts_catalog.claims.fact_claim_header CLUSTER BY (svc_dt_from, payer_id); -- Vacuum old Delta Lake versions (keep 7 days for time travel) VACUUM marts_catalog.claims.fact_claim_header RETAIN 168 HOURS; -- Check clustering effectiveness DESCRIBE DETAIL marts_catalog.claims.fact_claim_header;
Time Travel for HEDIS Reproducibility
Reconstruct historical data snapshots for audit and restatement
-- Query member eligibility as of HEDIS measurement date -- Critical for HEDIS audit — must use data as-of measurement year end SELECT * FROM marts_catalog.member.dim_member TIMESTAMP AS OF '2025-12-31 23:59:59' WHERE plan_cd = 'COMMERCIAL' AND curr_rec_flg = TRUE; -- Compare current vs historical claims for restatement SELECT 'current' AS snapshot, COUNT(*) AS claim_count, SUM(paid_amt) AS total_paid FROM marts_catalog.claims.fact_claim_header WHERE YEAR(svc_dt_from) = 2025 UNION ALL SELECT 'as_of_jan_1' AS snapshot, COUNT(*) AS claim_count, SUM(paid_amt) AS total_paid FROM marts_catalog.claims.fact_claim_header TIMESTAMP AS OF '2026-01-01' WHERE YEAR(svc_dt_from) = 2025;
Incremental Merge for Claims Updates
Handle claim adjustments and voids efficiently
-- Merge claims updates into silver layer
-- Handles original, adjusted, and voided claims
MERGE INTO staging_catalog.claims.stg_claims_header tgt
USING (
SELECT *
FROM raw_catalog.claims.edi_837_raw
WHERE processed_flg = FALSE
AND received_ts > current_timestamp() - INTERVAL 1 DAY
) src
ON tgt.clm_nbr = src.clm_nbr
WHEN MATCHED AND src.claim_freq_cd = '8'
THEN DELETE -- void claim
WHEN MATCHED AND src.claim_freq_cd = '7'
THEN UPDATE SET -- corrected claim
tgt.bld_amt = src.bld_amt,
tgt.paid_amt = src.paid_amt,
tgt.prim_diag_cd = src.prim_diag_cd,
tgt.rec_updt_ts = current_timestamp()
WHEN NOT MATCHED
THEN INSERT *; -- new original claimdbt + Databricks for Healthcare
profiles.yml — Databricks connection
healthcare_dbt:
target: prod
outputs:
prod:
type: databricks
host: "{{ env_var('DATABRICKS_HOST') }}"
http_path: "{{ env_var('DATABRICKS_HTTP_PATH') }}"
token: "{{ env_var('DATABRICKS_TOKEN') }}"
catalog: marts_catalog
schema: claims
threads: 8
dev:
type: databricks
host: "{{ env_var('DATABRICKS_HOST') }}"
http_path: "{{ env_var('DATABRICKS_DEV_HTTP_PATH') }}"
token: "{{ env_var('DATABRICKS_TOKEN') }}"
catalog: marts_catalog_dev
schema: "dbt_{{ env_var('DBT_USER', 'dev') }}"
threads: 4dbt_project.yml — Databricks-specific config
models:
healthcare_dbt:
staging:
+materialized: view
+catalog: staging_catalog
+grants:
select: ['phi-analyst-group', 'data-engineer-group']
marts:
claims:
+materialized: incremental
+incremental_strategy: merge
+unique_key: clm_key
+catalog: marts_catalog
+file_format: delta
+liquid_clustered_by: ['svc_dt_from', 'payer_id']
+grants:
select: ['claims-analyst-group', 'phi-analyst-group']
member:
+materialized: incremental
+catalog: marts_catalog
+file_format: delta
+grants:
select: ['phi-analyst-group', 'data-engineer-group']
quality:
+materialized: table
+catalog: marts_catalog
+file_format: delta
+grants:
select: ['quality-analyst-group', 'phi-analyst-group']Validate your column naming against ISO-11179 standards using the free Naming Auditor →
Databricks Healthcare Best Practices
- →Sign BAA before loading PHI: Contact Databricks to execute a Business Associate Agreement before loading any protected health information. Run PHI workloads on dedicated clusters with appropriate network isolation configured in your cloud provider security groups.
- →Use Unity Catalog from day one: Do not start with legacy Hive metastore and migrate later — Unity Catalog migration is painful. Configure Unity Catalog before loading any healthcare data so access controls, lineage, and audit logging are active from the first data load.
- →Enable Change Data Feed on all Delta tables: Set delta.enableChangeDataFeed = true on all healthcare Delta tables. This enables efficient CDC-based downstream processing, simplifies incremental dbt model logic, and supports downstream streaming consumers without full table scans.
- →Use liquid clustering over Z-ORDER for new tables: On Databricks Runtime 13.3 and above, use CLUSTER BY instead of ZORDER BY for new claims and member tables. Liquid clustering is adaptive, does not require manual re-clustering, and handles data skew better for healthcare date-partitioned workloads.
- →Separate clusters by workload type: Use job clusters for ETL pipeline runs (cheaper, auto-terminates), SQL warehouses for analyst queries and dbt model execution, and shared interactive clusters only for development. Never run production HEDIS calculations on interactive clusters shared with development work.
- →Store PHI audit logs in immutable storage: Configure Unity Catalog audit logs to write to immutable cloud storage (S3 Object Lock or Azure Immutable Blob Storage) to satisfy HIPAA audit control requirements that logs cannot be altered or deleted within the retention period.
Frequently Asked Questions
Is Databricks HIPAA compliant?
Databricks offers a HIPAA-eligible configuration and will sign a Business Associate Agreement with covered entities and business associates handling protected health information. Databricks runs on your cloud provider infrastructure (AWS, Azure, or GCP) and leverages that provider's HIPAA-eligible services. HIPAA compliance is a shared responsibility — Databricks secures the platform while your organization configures Unity Catalog access controls, encryption, audit logging, and data governance policies appropriate for PHI workloads.
What is Databricks Unity Catalog and why does it matter for healthcare?
Unity Catalog is Databricks's unified governance layer providing centralized access control, data lineage, auditing, and discovery across all Databricks workspaces. For healthcare organizations, Unity Catalog enables fine-grained PHI access controls through row-level security and column masking policies, maintains complete data lineage from raw EDI ingestion through analytics marts, provides a centralized audit log of all PHI-touching queries for HIPAA audit control requirements, and enables data discovery with sensitivity classification for PHI fields across your entire Databricks lakehouse.
What is Delta Lake and how does it help healthcare data engineering?
Delta Lake is an open-source storage layer that adds ACID transaction support, schema enforcement, data versioning, and time travel capabilities to Apache Spark and cloud object storage. For healthcare data engineering, Delta Lake enables reliable upserts for slowly changing dimension member and provider tables, time travel queries for point-in-time eligibility analysis and HEDIS measurement year reproducibility, schema enforcement preventing corrupt EDI or HL7 data from reaching downstream analytics, and Z-ordering optimization that dramatically reduces query scan costs for large claims fact tables.
How does the medallion architecture work for healthcare data on Databricks?
The medallion architecture organizes healthcare data into three progressive layers: the bronze layer stores raw ingested data exactly as received from source systems including raw EDI 837 files, HL7 messages, and EHR extracts; the silver layer applies cleaning, validation, ISO-11179 column renaming, and type enforcement to produce standardized records; and the gold layer contains business-level dimensional models including fact_claim_header, dim_member with SCD Type 2 history, and HEDIS measure fact tables ready for analytics consumption. Each layer is implemented as Delta Lake tables with appropriate access controls.
Should I use Databricks or Snowflake for healthcare data?
The choice depends on your workload mix. Databricks excels at large-scale data engineering pipelines, machine learning and AI workloads, streaming data processing with Structured Streaming, and Python/Spark-heavy transformation work. Snowflake excels at SQL-first analytics, BI dashboard serving with high concurrency, data sharing with payer or provider partners, and teams where analysts outnumber data engineers. Many healthcare organizations use both: Databricks for ingestion, transformation, and ML, and Snowflake or Databricks SQL for analyst-facing query serving.
How do I implement row-level security for PHI in Databricks Unity Catalog?
Use Unity Catalog Row Filters to restrict which rows a user or group can query based on policy logic evaluated at runtime. Create a row filter function that joins the querying user's group membership to an access control mapping table defining authorized member populations, plan codes, or geographic regions. Apply the row filter to tables containing PHI using ALTER TABLE SET ROW FILTER. Row filters in Unity Catalog enforce restrictions even on direct table queries, making them more robust than view-based security for HIPAA minimum necessary access compliance.
How do I connect dbt to Databricks for healthcare transformations?
Use the dbt-databricks adapter which connects to Databricks SQL warehouses or All-Purpose clusters via the Databricks SQL connector. Configure your profiles.yml with your Databricks workspace host, HTTP path from your SQL warehouse or cluster, and a personal access token or service principal OAuth credentials. Set the default materialization to incremental for large healthcare fact tables and configure Delta Lake-specific settings including liquid clustering on service date and payer columns. Use dbt's grant configuration to enforce Unity Catalog access controls on all model outputs.
What is Databricks Structured Streaming for healthcare?
Databricks Structured Streaming enables continuous, near-real-time data processing where new data is processed as it arrives rather than in scheduled batch jobs. Healthcare use cases include streaming HL7 ADT messages from interface engines for real-time bed management analytics, processing claims status change events from clearinghouses within minutes of receipt, streaming lab result feeds from laboratory information systems for clinical alerting, and ingesting patient monitoring device data for ICU analytics. Structured Streaming writes to Delta Lake tables enabling downstream queries on continuously updated data.
Related Resources
From the Blog
Healthcare Data Lakehouse Architecture: Building on Delta Lake for Payers
9 min readRead Data ArchitectureOracle vs Databricks for Healthcare Data Architecture: Which Platform Should You Choose?
15 min readRead Healthcare Data PlatformsSnowflake vs Databricks for Healthcare Data: Which Should You Choose in 2026?
11 min readReadBrowse all healthcare data guides