Skip to content

CONCEPT Cited by 1 source

SQL on FHIR ViewDefinitions

SQL on FHIR ViewDefinitions is "a new HL7 standard that flattens nested FHIR resources into tabular views for analytics." (Source: sources/2026-05-27-databricks-building-a-fhir-native-health-data-platform-on-databricks-lakebase.) First wiki canonicalisation 2026-05-27.

Definition

FHIR resources are intentionally nested — a Patient resource contains arrays of name (each with arrays of given), arrays of telecom, arrays of address, etc. This shape is well-suited for transactional REST APIs but mismatched with the columnar tabular shape that analytics engines (Spark SQL, BigQuery, DuckDB, Trino, etc.) prefer.

A ViewDefinition is a declarative spec that names:

  • A FHIR resource type to flatten.
  • A set of column projections (FHIR-Path expressions over the nested resource → flat column values).
  • Optional filters / where clauses.

A FHIR engine that implements the ViewDefinition standard can take a ViewDefinition + a corpus of FHIR resources and produce a tabular view that any SQL-capable analytics engine can query natively.

Architectural role

The 2026-05-27 source positions SQL on FHIR ViewDefinitions as the standards-side bridge between FHIR's nested-resource shape and analytics-engine tabular shape. In the dual-access pattern from one FHIR dataset, ViewDefinitions are one of three standards-based access surfaces (alongside the FHIR API and SMART on FHIR).

The structural property that matters: because ViewDefinitions are an HL7 standard, the operational↔analytical bridge is portable across FHIR engines — any engine that implements the spec can produce the same tabular flattening of the same FHIR resources. The bridge ceases to be vendor-specific.

Why this matters for substrate design

In the FHIR-server-on-lakehouse-substrate pattern (Aidbox-on-Lakebase + Moonlink + Unity Catalog), ViewDefinitions matter for two reasons:

  1. Analytics queries don't have to traverse the FHIR API. A ViewDefinition over the Lakebase-resident FHIR resources produces flat tables that can be queried directly through Databricks-native Spark / SQL — bypassing the FHIR server's transactional access path entirely.

  2. The flattening is contract-stable. ViewDefinitions are spec'd at the HL7 level, so the same analytics query that works against today's FHIR substrate continues to work against tomorrow's — even if the substrate vendor changes.

Seen in

Caveats

  • Name-only disclosure in the source. No spec excerpts, no view-definition examples, no engine support matrix, no comparison to prior ad-hoc FHIR-to-tabular projections.
  • Engine adoption status not disclosed. Which FHIR servers / analytics engines implement the standard, what version, what coverage of FHIR-Path features — none disclosed.
  • No examples of canonical view definitions. US Core, CARIN, mCODE all imply specific tabular shapes that ViewDefinitions could codify, but the 2026-05-27 source does not provide examples.
  • Performance characteristics undisclosed. Whether ViewDefinitions are evaluated at query time (every read flattens) or materialised (flatten once into a Delta table and refresh on change) is not addressed.
Last updated · 542 distilled / 1,571 read