Open retail data → governed inventory analytics → Python & SQLite → dimensional modeling → a complete eight-page Power BI report.

Explore the full project →  ·  View all 8 dashboard pages  ·  Read the case study  ·  Explore the engineering

The project retains the original historical Power BI report, its source-controlled PBIP / PBIR / TMDL, all eight real screenshots, licensed public retail RAW datasets, historical analytical tables, and a separately executable Python/SQLite simulation and validation pipeline.

Evidence-based modeling: it distinguishes observed sales and returns (OBS) from simulated inventory, service and supplier flows (SIM) and exploratory stock signals (EXP). The reconstructed simulation is not identical to the historical scenario; Power BI Desktop refresh remains to be verified independently.

Browse the evidence map · See CI checks · Open the native Power BI project

I work at the intersection of healthcare domain knowledge, retail and supply-chain operations, business intelligence, data analytics, and analytics engineering.

My projects typically follow this pattern:

Source → Data Quality → Canonical Model → SQL / Python → Semantic Model → Governed KPIs → BI Delivery → Independent Validation → Decision Support

The goal is not to make a chart look impressive. The goal is to make the number behind the chart defensible.

That means I consistently focus on:

• explicit analytical grain before aggregation;
• governed KPI definitions and ratio-of-totals logic;
• missing / suppressed / unavailable values that remain semantically distinct from zero;
• independent reconciliation across SQL, Python, DAX, Excel, or source artifacts;
• preservation of source anomalies instead of silently “cleaning” them away;
• lineage, reproducibility, tests, and CI as part of analytics delivery;
• clear boundaries between descriptive evidence and unsupported causal claims.

These are not generic demo claims — they come from implemented, documented projects in this GitHub account.

View repository →

My most complete interoperability and claims-engineering project.

CMS Blue Button sandbox → OAuth 2.0 + PKCE → FHIR Patient/Coverage/EOB → governed RAW → canonical claims grains → PostgreSQL analytics → TMDL semantic model → PBIR report → CI validation

Why it matters: healthcare claims data contains multiple nested grains. The project preserves claim, item, diagnosis, procedure, care-team, supporting-information, terminology, and financial meaning rather than flattening everything into one misleading table.

View repository →

A governance-first implementation built on public CMS Medicare data.

RAW → STAGING → ANALYTICS + GOVERNANCE → DQ rules → lineage → governed KPI contracts → SQL/Python reconciliation → source-controlled Power BI

Highlights include source fingerprinting, field-level lineage, preserved source conflicts, weighted utilization/payment metrics, and explicit publication boundaries.

View repository →

A payer-transparency analytics implementation where availability is modeled as data, not guessed from blanks.

The project separates issuer and plan grains, preserves source anomalies, uses ratio-of-totals KPI semantics, and reconciles the saved Power BI model against independent Python baselines.

View repository →

Official Saudi Ministry of Health yearbooks transformed into a governed canonical model across capacity, activity, workforce, and regional healthcare resources.

Python discovery → canonical CSVs → SQL Server star schema → DAX semantic model → 7-page PBIR report → layered validation

View repository →

A production-style synthetic hospital analytics platform combining:

clinical activity · claims · finance · budget · workforce · operations · capacity · technology

The project uses PostgreSQL, dimensional modeling, explicit fact grains, SQL regression, Python analytics, Power BI, and scale testing up to a 20K synthetic source generation benchmark.

View repository →

End-to-end customer and growth analytics built from the public UCI Online Retail II dataset.

Transaction governance → SQL Server star schema → repeat behavior → RFM → acquisition cohorts → retention → cancellations → Power BI → SQL-driven Excel management outputs

I use a simple rule:

If a KPI cannot survive grain review, reconciliation, and evidence review, it is not ready for a dashboard.

Every fact table starts with an explicit business grain and key contract.

Duplicates, orphan keys, missing mappings, availability states, impossible values, and source conflicts stay visible.

SQL, Python, DAX, Excel, and UI outputs should reconcile to the same governed business meaning.

Claims are not flattened into claim items. Finance is not joined directly to operations. Issuer metrics are not duplicated across plan rows.

Unknown, unavailable, suppressed, mapping-pending, zero, and not-applicable are different analytical states.

Screenshots, dashboards, or presentation graphics never override the source, model, tests, or reconciliation evidence.

Where possible, repositories include regression tests, reproducibility checks, source/generated parity, privacy controls, and GitHub Actions quality gates.

My background combines pharmacy / healthcare domain knowledge with business and analytics training.

That helps me work on problems where technical correctness alone is not enough — the analyst also needs to understand the operational meaning of claims, utilization, warehouse and distribution-center inventory, replenishment, commercial performance, supplier service, customer behavior, and management KPIs.

Pharmacy background · MBA · Data Analyst Associate · Healthcare / BI / Analytics Engineering focus

I am focused on full-time opportunities in:

Data Analytics · Business Intelligence · Healthcare Analytics · Retail / Supply Chain / Inventory Analytics · BI / Reporting · Commercial & Performance Analytics · Revenue Cycle / Claims Analytics · Analytics Engineering

Especially roles where Power BI + SQL + Python + domain knowledge + data quality + decision support are used together.