SQL-on-FHIR vs. Firemetrics: zwei grundverschiedene Ansätze für FHIR-Analytics

Suche

SQL-on-FHIR vs. Firemetrics: Zwei sehr verschiedene Ansätze, um FHIR Daten zu analysieren

Auf der _Analytics on FHIR Conference 2025_ wurde SQL-on-FHIR als ein wichtiger Schritt vorgestellt, um FHIR-Daten besser für analytische Zwecke nutzbar zu machen. Erfreulich ist, dass sich die Branche zunehmend von der reinen Frage der Datenaustauschbarkeit hin zu der wesentlich spannenderen Frage bewegt, wie wir FHIR-Daten konkret für echte, praxisnahe Analysen und operative Workflows nutzen können.

Während SQL-on-FHIR zunehmend Aufmerksamkeit erhält, stellt sich eine naheliegende Frage: Wenn es SQL-on-FHIR gibt, warum sollte man dann noch eine FHIR-basierte Interoperabilitäts- und Analyseplattform wie Firemetrics benötigen? Dieser Artikel gibt eine klare Einordnung, indem er die Unterschiede in Zweck, Architektur und Leistungsfähigkeit zwischen SQL-on-FHIR und Firemetrics herausarbeitet.

SQL-on-FHIR bietet eine standardisierte, herstellerneutrale SQL-Schnittstelle, indem virtuelle relationale Views über FHIR-Ressourcen definiert werden. Das Konzept ist auf Interoperabilität und leichte Abfragen ausgelegt und damit ein wertvoller Baustein für Organisationen, die schnellen SQL-Zugang zu den in ihrem FHIR-Server gespeicherten Daten benötigen.

Firemetrics hingegen ist als vollständige analytische Datenplattform konzipiert. Die Plattform materialisiert FHIR-Ressourcen in ein leistungsfähiges relationales Schema, bildet FHIR-Konzepte wie Perioden und Codings semantisch korrekt ab, löst Referenzen automatisch auf und unterstützt multimodale Daten wie DICOM. Zudem umfasst Firemetrics Ingestion-Pipelines, Monitoring-Dashboards, SQL-Hilfsfunktionen und sogar einen vollwertigen FHIR-Server. Die Plattform ist nicht nur dazu gebaut, FHIR abzufragen, sondern FHIR-Daten in analytischer Skalierung operativ nutzbar zu machen.

Den Unterschied zu verstehen, ist essenziell: SQL-on-FHIR ist eine Zugriffsschicht; Firemetrics ist eine Analytics-Engine. SQL-on-FHIR ermöglicht konsistente und portable SQL-Abfragen; Firemetrics ermöglicht Echtzeit-Dashboards, komplexe temporale Analysen, KI-Pipelines und Bilddaten-Analytics – Anwendungen, die mit rein virtuellen, JSON-basierten Views schlicht nicht realisierbar wären. Dieser Artikel zeigt auf, welche Rolle SQL-on-FHIR spielt, welche Rolle Firemetrics spielt und wie beide Entwicklungen Ausdruck des wachsenden industriellen Fokus auf konkrete, nutzenstiftende FHIR-Anwendungsfälle sind.

### SQL-on-FHIR vs. Analyse von FHIR-Daten mit Firemetrics

### Warum eine standardisierte SQL-Schicht für echte Gesundheits-Analysen nicht ausreicht

Mit der zunehmenden FHIR-Adoption im Gesundheitswesen hat sich die Diskussion endlich von „Wie tauschen wir Daten aus?“ zu „Wie generieren wir tatsächlichen operativen und analytischen Mehrwert?“ verschoben. Dieser Perspektivwechsel war überfällig – und ist äußerst positiv. 🚀

SQL-on-FHIR ist eine der vielversprechendsten Entwicklungen in diesem Kontext. Es berücksichtigt, dass Analyst:innen und Ingenieur:innen SQL-Zugriff auf FHIR-Daten benötigen – nicht tausende paginierte REST-Aufrufe oder fehleranfälliges JSON-Parsing. Durch die Definition eines standardisierten relationalen Views macht SQL-on-FHIR FHIR-Daten zugänglicher und besser analysierbar als zuvor.

Doch SQL-on-FHIR ist nur ein Teil des Analytics-Puzzles. Viele Organisationen erkennen inzwischen, dass SQL-on-FHIR ein völlig anderes Problem löst als Plattformen wie Firemetrics.

Dieser Artikel beleuchtet diese Unterschiede und zeigt, warum bestimmte reale Workflows – insbesondere solche, die bereits mit Firemetrics umgesetzt wurden – mit SQL-on-FHIR allein nicht umsetzbar wären.

### Was SQL-on-FHIR tatsächlich bietet

Im Kern ist SQL-on-FHIR eine dünne Abstraktionsschicht. Implementierende Systeme stellen typischerweise eine Reihe von SQL-Views bereit, die die JSON-Strukturen von FHIR in relationale Tabellen „abflachen“. Teams können somit SQL-Abfragen schreiben, ohne die Systemarchitektur zu verändern.

SQL-on-FHIR eignet sich ideal für:

• leichte Exploration von FHIR-Daten
• einfache Berichte
• standardisierte SQL-Zugriffe
• Organisationen, die SQL nutzen möchten, ohne neue Infrastruktur einzuführen

Für diese Szenarien ist SQL-on-FHIR ein bedeutender Fortschritt.

Es war jedoch nie als Hochleistungs-Analytics-Engine gedacht. Die Views sind virtuell, und im Hintergrund müssen weiterhin JSON-Felder extrahiert, Arrays abgeflacht und Referenzstrings geparst werden. Das funktioniert bei kleinen und mittleren Lasten, zeigt jedoch schnell Grenzen, sobald anspruchsvollere Analytics ins Spiel kommen.

### Wo SQL-on-FHIR an seine Grenzen stößt

Hier die von Ihnen gewünschte Übersichtstabelle – sie zeigt kompakt, was SQL-on-FHIR _nicht_ löst und warum das relevant ist.

Was SQL-on-FHIR** **_nicht_** **löst

Sobald Organisationen mehr wollen als einfache Abfragen, werden diese Limitierungen spürbar.

### Wie Firemetrics Analytics völlig anders angeht  🔍

Firemetrics denkt die Analytics-Pipeline von Grund auf neu. Statt FHIR zu virtualisieren, materialisiert Firemetrics FHIR-Ressourcen in ein normalisiertes, indexierbares relationales Schema in PostgreSQL.

Zu den wesentlichen Vorteilen gehören:

• Physische Tabellen, basierend auf FHIR StructureDefinitions
• Range Types (tstzrange, daterange) für temporale Daten
• Normalisierte Codings als Integer-IDs
• Automatische Referenzauflösung
• DICOM-Ingestion mit SQL-zugänglichen Metadaten
• Grafana-Dashboards für Echtzeit-Monitoring
• SQL-Hilfsfunktionen für FHIR-spezifische Logik
• Ein No-Code-SQL-Builder für Analyst:innen

Während SQL-on-FHIR vor allem _Zugriff_ ermöglicht, ist Firemetrics für Analytics in großem Maßstab entwickelt.

Zur Verdeutlichung:

### SQL-on-FHIR vs. Firemetrics – Unterschiedliche Zwecke, unterschiedliche Ergebnisse

### Reale Firemetrics-Anwendungsfälle, die mit SQL-on-FHIR nicht möglich wären

Die Firemetrics-Dokumentation beschreibt mehrere reale Szenarien, die zeigen, wie groß der Unterschied zwischen „FHIR abfragen“ und „FHIR-Analytics operationalisieren“ ist.

#### 1\. Pädiatrisches MRT-Terminmanagement

Dieses Szenario verbindet ServiceRequest-, Patient-, Location- und Procedure-Daten, löst Referenzen auf, interpretiert Perioden und erzeugt Termin-Slots in Echtzeit.

SQL-on-FHIR kann diese Last und Komplexität nicht zuverlässig bewältigen.

#### 2\. Dosis-Analytics in der Radiologie (DICOM SR)

Firemetrics liest DICOM-Studien ein, extrahiert strukturierte Metadaten und verbindet sie mit FHIR ImagingStudy.

SQL-on-FHIR besitzt keinerlei Mechanismen für DICOM – weder für Ingestion noch für Analytics.

#### 3\. Operative Echtzeit-Dashboards

Firemetrics ermöglicht Grafana-Dashboards mit sekundenschnellen Aktualisierungen. Diese basieren auf schnellen relationalen Abfragen großer Tabellen.

SQL-on-FHIR-Views könnten diese Frequenz nicht halten und würden den FHIR-Server überlasten.

#### 4\. Komplexe temporale Analysen

Firemetrics nutzt PostgreSQL-Range-Typen zur Abbildung von FHIR-Perioden und teilweisen Datumsangaben. So werden mächtige zeitbezogene Analysen möglich.

SQL-on-FHIR reduziert diese Strukturen auf einfache Strings – ein erheblicher Verlust an Semantik.

### Wann SQL-on-FHIR sinnvoll ist – und wann Firemetrics

SQL-on-FHIR eignet sich, wenn Organisationen einen einfachen SQL-Zugang zu ihrem bestehenden FHIR-Server möchten, ohne Infrastruktur zu verändern. Für Reporting, Exploration und überschaubare Datenmengen ist es gut geeignet.

Firemetrics ist die richtige Wahl, wenn Analytics zentral für die Organisation ist: Echtzeit-Dashboards, multimodale Workflows, temporale Analysen, KI-Pipelines, hohe Datenmengen oder klinisch integrierte Entscheidungsunterstützung. Besonders gilt das für Einrichtungen, die interoperable Central Data Repositories betreiben und große Datenmengen für Versorgung, Administration und Forschung verarbeiten.

Kurz gesagt: SQL-on-FHIR ist eine Schnittstelle. Firemetrics ist eine Analytics-Plattform. Beides ist wertvoll - aber für grundlegend unterschiedliche Aufgaben konzipiert.