Slides

scan to open

QR code — open these slides
Health Samurai

Health Samurai · Vitalis 2026

Business and Clinical Intelligence on FHIR

Plug-and-play analytics, CDS and AI on standardized health data

Nikolai Ryzhikov · Vitalis 2026 · Gothenburg · 7 May

Speaker

Nikolai Ryzhikov

Nikolai Ryzhikov
  • 15+ years in healthcare interoperability
  • Co-author of the SQL on FHIR specification (HL7)
  • Active contributor to FHIR standards and community
  • Today: patterns observed across deployments in EU, US and AU

The Problem

The economics of locked data

Locked legacy data is expensive.

Every integration

a separate project

Every report

manual data wrangling

Every analytics question

months of engineering

Every AI experiment

hits a data wall

The cost is paid in the wrong currency:

clinician time · research delay · missed insights · public-health budget burned on plumbing.

The Dividend

What standardization actually buys you

Standardized data + standardized logic = freed resources.

Without Standards

  • N integrations per use case
  • Reports built per request
  • AI projects start with ETL
  • Clinical logic locked in vendors

With FHIR-Native Intelligence

  • One model reused across systems
  • Self-service BI on shared data
  • AI starts with insight
  • Portable, computable rules

The dividend goes back to treatment, optimization, and discovery.

Forces Converging

FHIR is the near future

Two forces are converging on FHIR.

Bottom-up · Architecture

  • FHIR-native EHRs emerging across the EU
  • Hospitals, digital health, AI startups default to FHIR
  • Charité runs ~10 FHIR projects — not regulation, better architecture

Top-down · Regulation

  • EHDS mandates FHIR for cross-border health data
  • Patient summary, prescriptions, labs, images, discharges — 2027+
  • Secondary use (research, policy, AI) — same FHIR substrate

FHIR isn't the future. It's the near future.

Analytics Gap

But exchange isn't analytics

FHIR was designed to move data — not to query it.

  • Deeply nested · references instead of joins · codes inside arrays
  • Every team flattens it again, in their own way
  • Result: every dashboard, every quality measure, every AI pipeline — custom plumbing

SQL on FHIR makes FHIR analytics-friendly —

without changing the standard, without leaving the ecosystem.

SQL on FHIR

SQL on FHIR — the bridge

Portable · Tabular · Projections of FHIR resources.

# ViewDefinition — flatten Observations into a table
resource: Observation
select:
  - column: id,         path: id
  - column: patient_id, path: subject.reference
  - column: code,       path: code.coding.where(system='loinc.org').code
  - column: value,      path: valueQuantity.value
  - column: date,       path: effectiveDateTime
where:
  - path: status = 'final'

One declarative spec flat table any SQL engine.

Roles

Decouple authors, vendors, users

Authors

HL7 · NCQA

research consortia

define views & measures

Vendors

multiple

open & SaaS engines

implement engines

Users

hospitals · research

AI startups

run queries

Write the rule once. Run it anywhere. By anyone.

Operations

One spec, three operations

Operation
Use case
$run
Sync execution — small datasets, patient-scoped
$export
Async batch — bulk export to Parquet / CSV / NDJSON
$materialize
Near real-time — keep flat tables in sync

Outputs flow into

DuckDB ClickHouse Postgres BigQuery Snowflake Databricks Spark

Ecosystem

The BI ecosystem already moved to FHIR

  • Snowflake — FHIR connector + ViewDefinition support
  • Databricks — Health & Life Sciences Lakehouse, native FHIR ingestion
  • AWS HealthLake — FHIR-native data store
  • Google Cloud Healthcare API — FHIR store + BigQuery export
  • Salesforce Health Cloud — FHIR APIs first-class

You don't need to migrate off FHIR to do BI.

The BI tools came to FHIR.

Tableau · Power BI · Looker · Metabase plug into flattened views directly.

AI

AI is only as good as the data it sees

Garbage in → garbage AI.

  • LLMs are now native FHIR consumers — frontier models trained on it
  • Patients pull EHR data into AI assistants (US: zero demand → mainstream in 18 months)
  • Agents extract Epic records via FHIR and reason over them
  • Agents are excellent at SQL. Flatten FHIR with SoF → agents query it directly.
  • Local sovereign models (EU-hosted) reach today's frontier in 1–2 years

FHIR + SQL on FHIR = the substrate AI was waiting for.

Clinical Logic

CQL — computable clinical logic

SQL on FHIR handles "what data?". CQL handles "what does it mean clinically?"

define "Diabetic patients with poor control":
  [Condition: "Diabetes mellitus"] DM
    where exists (
      [Observation: "HbA1c"] O
        where O.value > 7 '%'
        and O.effective during "Last 6 months"
    )
Quality measures (HEDIS, eCQM, national programs) CDS Hooks Cohort definitions for research Population health monitoring

Same pattern: write once, run anywhere.

Architecture

Architecture — CDR / FHIR Data Platform

Sources EHRs · HL7 v2 · X12 · devices · labs CDR / FHIR DATA PLATFORM FHIR-native storage · MPI · terminology · ACL TRANSACTIONAL · SMART FHIR API ANALYTICAL · SQL ON FHIR CLOSING LOOP · CDS HOOKS APPS portals · SMART BI / CI / AI analytics · agents CDS back into EHR & workflow

One platform · three faces: transactional (apps) · analytical (BI / AI) · closing the loop (CDS back into workflow).

Closing the loop

Plug-and-play intelligence is what we build on top.

FHIR exchange was the foundation.

  • Standardized data + standardized logic = lower cost per use case
  • AI is the new driver — and FHIR + SoF is the substrate it needed
  • The technology is ready. The ecosystem is ready.

Make data work for better health.

Thank you · Questions

nikolai@health-samurai.io·sql-on-fhir.org·cql.hl7.org

LinkedIn

Nikolai Ryzhikov

LinkedIn QR code — Nikolai Ryzhikov
1 / 14