ICU Respiratory Analytics
Enterprise BI Data Product

The Problem Worth Solving

Most analytics portfolio projects demonstrate a skill in isolation: a Pandas notebook here, a Power BI dashboard there. What they rarely show is the full chain — from a real, messy dataset through a validated pipeline to a BI-ready data model that a team could actually trust in production.

This project was built to close that gap deliberately. Using the MIMIC-III Waveform Database — a publicly available dataset of ICU patient vital signs from PhysioNet — the goal was to build exactly the kind of system a Data Centre of Excellence maintains: automated, validated, documented, and maintainable by anyone on the team.

The domain choice was intentional. Respiratory biometrics — SpO₂, respiratory rate, heart rate, blood pressure — map directly to the kind of measurement data that healthcare analytics teams work with daily: time-series measurements, patient cohorts, clinical thresholds, and risk stratification. The engineering challenge is identical regardless of whether the underlying metric is a vital sign or a manufacturing sensor reading.

How It's Built

The system has three layers: an ETL and validation layer that processes raw data, a Power BI export layer that generates the star-schema model, and an interactive dashboard layer for exploratory analysis. All three are orchestrated by a single pipeline runner with gate-based validation logic.

The data_pipeline.py orchestrator is the spine of the system. It runs each stage sequentially, logging every gate result before proceeding. A FAIL at any gate halts the pipeline — outputs are never generated from data that has not passed validation.

The Four-Gate Pipeline

Most pipelines validate reactively — you notice something is wrong when a dashboard shows nonsense. This pipeline validates proactively, at four explicit checkpoints, with structured JSON logging at each one.

Each gate writes a timestamped PASS / WARN / FAIL entry to a structured JSON audit log. A complete report is generated per run. You can always answer: when did this pipeline last run cleanly, and what did it find?

Power BI Star Schema

The export layer produces a proper star schema — not a flat CSV handed off to an analyst to wrestle into shape. The model is designed for query performance and self-service usability: dimension tables for filtering and slicing, a central fact table for aggregation, and pre-authored DAX measures so analysts aren't writing the same CALCULATE expressions from scratch.

Pre-authored DAX measures exported alongside the schema:

Average SpO2 =
  AVERAGE(fact_vitals[spo2])

Hypoxemia Rate % =
  DIVIDE(
    COUNTROWS(FILTER(
      fact_vitals,
      fact_vitals[hypoxemia_flag]=1)),
    COUNTROWS(fact_vitals)
  ) * 100

High Risk Patients =
  CALCULATE(
    DISTINCTCOUNT(
      dim_patient[patient_key]),
    dim_patient[risk_category]
      = "High"
  )

agg_hourly_vitals.csv

Hourly rollups pre-computed
at export for dashboard
performance at scale.

Five-Module Streamlit Application

The dashboard is built for multi-level interrogation. A clinical or analytics team can move from cohort-level KPIs to individual patient trajectories to statistical hypothesis testing within the same application. All modules share a real-time patient filter that cascades across pages.

Every chart supports CSV download. The application is stateless and configuration-driven via config.py — clinical thresholds and parameters are defined once and respected everywhere.

Built to Be Maintained

The features matter less than what they reveal about underlying discipline. Each engineering choice was made with the same question in mind: what does it take for a team to own and extend this independently?

What This Project Shows

Technology Stack