Slides

scan to open

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

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

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

DuckDBClickHousePostgresBigQuerySnowflakeDatabricksSpark

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 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 HooksCohort definitions for researchPopulation health monitoring

Same pattern: write once, run anywhere.

Architecture

Architecture — CDR / FHIR Data Platform

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

Nikolai Ryzhikov