Healthcare Interoperability Platform

Summary

FHIR is the standard for exchanging clinical data, but its deeply nested resource model resists the flat, tabular shape that analytics and machine-learning pipelines need. I work on a SQL-on-FHIR engine — a Rust core with a Python interface — that turns FHIR resources into queryable, analytics-ready views.

The problem

Clinical data arrives as deeply nested FHIR resources; analysts and data scientists need flat tables. Hand-written extraction code is slow to build, easy to get wrong, and different for every project — the SQL-on-FHIR specification exists precisely to standardize that transformation layer.

Constraints

• —

  Transformations must stay faithful to the FHIR specification — clinical data cannot be silently dropped or reshaped.

• —

  One core serves two audiences: engineers consuming it from Rust, data teams consuming it from Python.

What I did

• —

  Build SQL-on-FHIR view bindings that extract and transform HL7 FHIR clinical data for analytics and machine-learning workflows.

• —

  Develop the Python interface over the Rust core, so data teams can consume FHIR views without touching Rust.

Architecture

A Rust core implements the SQL-on-FHIR view specification; native Python bindings expose the same views to data tooling.