SQL-on-FHIR vs. Firemetrics - Understanding Two Very Different Approaches to FHIR Analytics 🔥

SQL-on-FHIR vs. Firemetrics: Two very different approached to analyzing FHIR data

At the Analytics on FHIR Conference 2025, SQL-on-FHIR was introduced as an important step forward in making FHIR data more accessible for analytical use. It is encouraging to see the industry shifting from simply exchanging FHIR data toward the much more impactful question of how we can actually use FHIR data for concrete, real-world analytics and operational workflows.

As SQL-on-FHIR gains attention, a natural question arises: If SQL-on-FHIR exists, why would anyone need a FHIR-based interoperability and analytics platform like Firemetrics? This article provides a clear perspective on that question by outlining the differences in purpose, architecture, and capabilities between SQL-on-FHIR and Firemetrics.

SQL-on-FHIR offers a standardized, vendor-neutral SQL interface by defining virtual relational views over FHIR resources. It is designed for interoperability and lightweight querying, making it a valuable development for organizations that want quick SQL access to the data already stored inside their FHIR servers.

Firemetrics, in contrast, is built as a full analytical data platform. It materializes FHIR resources into a high-performance relational schema, semantically models FHIR constructs such as periods and coded values, resolves references automatically, and supports multimodal data like DICOM. It includes ingestion pipelines, monitoring dashboards, helper SQL functions, and a full FHIR server. Firemetrics is designed not just to query FHIR but to operate on it at analytical scale.

Understanding the difference is essential: SQL-on-FHIR is an access layer; Firemetrics is an analytics engine. SQL-on-FHIR enables consistent, portable SQL queries; Firemetrics enables real-time dashboards, complex temporal analysis, AI pipelines, and imaging analytics - use cases that simply cannot be achieved using virtual JSON-based views alone. This article clarifies where SQL-on-FHIR fits, where Firemetrics fits, and how both together represent an exciting evolution in the industry’s growing focus on practical, outcome-driven use of FHIR data.

SQL-on-FHIR vs. Analytics of FHIR Data with Firemetrics

Why a Standardized SQL Layer Isn’t Enough for Real Healthcare Analytics

As more healthcare organizations embrace FHIR, the conversation has finally shifted from “How do we exchange data?” to “How do we use this data for real operational and analytical value?” That shift is long overdue - and very positive. 🚀

SQL-on-FHIR represents one of the most encouraging developments in this space. It acknowledges that analysts and engineers want SQL access to FHIR data, not thousands of paginated REST calls or brittle JSON scraping. By defining a standardized relational view, SQL-on-FHIR makes FHIR more queryable than ever before.

But SQL-on-FHIR is only one piece of the analytics puzzle. And many organizations are learning that it solves a very different problem than platforms like Firemetrics.

This article explores the differences and explains why certain real-world workflows would not be feasible using SQL-on-FHIR alone.

What SQL-on-FHIR Actually Provides

At its heart, SQL-on-FHIR is a thin abstraction layer. Implementers typically expose a set of SQL views that flatten FHIR’s JSON structures into relational tables. This lets teams write SQL queries without rearchitecting their systems.

SQL-on-FHIR is ideal for lightweight exploration of FHIR data, simple reporting, standardizing SQL access, and organizations that want SQL without introducing new infrastructure. For these scenarios, SQL-on-FHIR is a meaningful step forward. But SQL-on-FHIR was never intended to be a high-performance analytics engine. Its views are virtual, and under the hood, they still rely on extracting values from JSON fields, flattening arrays, and parsing reference strings. This works for small or moderate workloads - but limitations appear quickly when analytics become more demanding.

Where SQL-on-FHIR Reaches Its Limits

Here is the table you wanted to keep — the essential overview of what SQL-on-FHIR does not solve and why that matters.

What SQL-on-FHIR Does Not Solve

Area SQL-on-FHIR Does NOT Solve	Why It Matters
Performance on large datasets	JSON flattening happens at query time; joins slow down quickly.
Efficient joins across nested resources	No pre-resolved relationships; JOINs must parse reference strings.
FHIR date/period semantics	Partial dates and Periods become plain text; temporal logic breaks.
Code normalization	{system, code} pairs cannot be indexed or optimized easily.
Reference resolution	No FK-like links; everything remains string-based.
Real-time or operational dashboards	Views are too slow for high-frequency refreshes.
Multimodal data (e.g., DICOM)	Not supported at all.
Ingestion and ETL pipelines	SQL-on-FHIR does not define how data gets into the warehouse.
AI/ML feature extraction	JSON-based views lack structure and speed for large-scale ML.

Once organizations reach for real analytics - not just simple querying - SQL-on-FHIR’s limitations become clear.

How Firemetrics Approaches Analytics Differently  🔍

Firemetrics rethinks the entire analytics pipeline. Instead of virtualizing FHIR, it materializes FHIR resources into a normalized, indexable, relational schema in PostgreSQL.

Some of the distinct advantages include:

• Physical tables derived from FHIR StructureDefinitions

• Range types (tstzrange, daterange) to model temporal data

• Normalized code systems using integer identifiers

• Automatic reference resolution

• DICOM ingestion with SQL-accessible metadata

• Grafana dashboards for real-time monitoring

• Helper SQL functions for FHIR-specific logic

• A no-code SQL builder for analysts

Where SQL-on-FHIR is about access, Firemetrics is about analytics at scale.

To illustrate:

SQL-on-FHIR vs Firemetrics - Different Purposes, Different Outcomes

Category	SQL-on-FHIR	Firemetrics
Schema	Virtual views	Physical, optimized relational schema
Performance	Limited by JSON extraction	High-performance indexed tables
Date modeling	Plain strings	Semantic temporal types
Reference handling	String-based	Relational resolution
Multimodal support	FHIR only	FHIR + DICOM
Operational dashboards	Not practical	Built-in support
AI/ML readiness	Limited	Fast, structured feature extraction
Ideal for	Lightweight reporting	Enterprise-grade analytics

Real Firemetrics Use Cases That SQL-on-FHIR Could Not Support

The examples of real-world use cases that were implemented with the Firemetrics analytics platform illustrate the difference between “querying FHIR” and “operationalizing FHIR analytics.”

1. Pediatric MRI Scheduling and Slot Management

This workflow joins ServiceRequest, Patient, Location, and Procedure data, resolves references, interprets periods, and generates scheduling slots. It requires real-time updates and multi-level joins.

SQL-on-FHIR’s view-based model cannot sustain these operations or their performance requirements.

2. Radiology Dose Analytics Using DICOM SR

Firemetrics ingests DICOM studies, extracts structured metadata, and joins these data with FHIR ImagingStudy resources.

SQL-on-FHIR has no mechanism to ingest DICOM, let alone integrate it into analytics workflows.

3. Real-Time Operational Dashboards

Firemetrics supports Grafana dashboards that refresh every few seconds. These depend on fast relational queries across large, indexed tables.

SQL-on-FHIR’s JSON-based views would not keep up — dashboards would time out or overload the FHIR server.

4. Complex Temporal Analytics

Firemetrics uses PostgreSQL’s range types to represent FHIR Periods and partial dates accurately, enabling powerful temporal reasoning.

SQL-on-FHIR collapses these structures into plain strings, losing critical semantics.

When to Use SQL-on-FHIR, and When to Use Firemetrics

SQL-on-FHIR makes sense when organizations want simple SQL access to their existing FHIR server without restructuring anything. It works well for simple reporting, exploration, and modest data volumes.

Firemetrics is the right choice when analytics are core to operations: real-time dashboards, multimodal workflows, temporal analytics, AI pipelines, high ingestion throughput, or clinically integrated decision tools. This is especially the case for healthcare organizations, such as hospitals or health systems that implement interoperable Central Data Repositories that accumulate large amounts of data for patient care, administrative processes and research.

In short: SQL-on-FHIR is an interface. Firemetrics is an analytics platform. Both are valuable - but they are designed for fundamentally different jobs.