From FHIR API to SQL in minutes · Apache 2.0
Query FHIR with
plain SQL.
Pull HL7 FHIR R4 from any compliant API into a columnar, MySQL-compatible database and write plain SQL for population analytics. No FHIRPath, no JSON-flattening pipelines, no proprietary driver.
- Apache 2.0
- FHIR R4 · 146 resources
- MySQL wire protocol
- StarRocks engine
- Power BI
- Tableau
- dbt
- DBeaver
- Metabase
- Databricks
- JDBC / ODBC
Why Hyperion
Stop wrestling FHIR. Just write SQL.
FHIR is built for exchange: deeply nested JSON, one patient at a time. The moment you want a population answer, you're hand-rolling FHIRPath or flattening pipelines forever. Hyperion skips all of it.
-
It's just SQL
Tables and columns map to FHIR R4 directly, so
JOIN,GROUP BY, and your existing dbt models work unchanged. Nothing new to learn. The schema is the spec. -
MySQL on the wire
BI tools, JDBC/ODBC clients, ORMs, and migration runners connect with zero special handling.
-
The schema generates itself
Every table is derived mechanically from the FHIR R4 JSON Schema. New element? Re-bootstrap. Never hand-write DDL.
-
Profiled data, same tables
US Core and other profiles constrain the same base R4 resources, so profiled data lands straight into existing columns.
-
Compute & storage scale apart
Built on shared-data StarRocks. Burst compute for a heavy window, shrink when idle; data lives in Blob, ADLS, S3, or MinIO.
-
Live or batch, your call
Stream-load every change in real time in Azure mode via Service Bus, or run a single batch pass locally. Clone, point it at a FHIR endpoint, and start querying in minutes.
One table per resource
Nested FHIR in. Flat columns out.
Hyperion flattens each FHIR R4 resource into a table in _hyperion_core_. Columns mirror the resource, so the shape you query is the shape you already know.
{
"resourceType": "Patient",
"id": "a1b2",
"gender": "female",
"birthDate": "1984-03-11",
"name": [{ "family": "Reyes" }]
}
id gender birth_date name_family
──── ────── ────────── ───────────
a1b2 female 1984-03-11 ["Reyes"]
Repeating FHIR elements (like name) become ARRAY columns: one row per resource, no exploding.
Scope
What Hyperion is not
-
Not a FHIR server
It consumes a FHIR API; it does not serve one.
-
Not an EHR
It's an analytics layer downstream of your clinical systems.
-
Not a validator
No terminology service. Resources are ingested as-is.
-
Not a transactional store
The engine is columnar, built for analytics, not CRUD.
Quickstart
Up and running in one command
Docker Desktop or Engine 24+, ~10 GB disk, ~8 GB RAM. First run is ~5-10 min.
# Clone, configure, launch the full local demo
git clone https://github.com/Health-Chain-Inc/hyperion.git
cd hyperion
cp .env.example .env
docker compose up --build
Documentation
Dig deeper
This page is the short version. Everything below lives in the repo.
-
Architecture
How the pieces fit: diagram, key design, operating modes, repo layout.
-
Example queries
SQL against the FHIR-shaped tables and the shared reference tables.
-
Configuration
The complete environment-variable reference for local and Azure modes.
-
Development
Dev workflow, common operations, tests, and advanced compose usage.
-
Azure deployment
Hybrid Azure walkthrough: FHIR, Service Bus, Blob/ADLS, scaling up.
-
Troubleshooting
Symptoms and fixes for the most common setup and query issues.