Skip to content

CONCEPT Cited by 1 source

FHIR

FHIR (Fast Healthcare Interoperability Resources) is the HL7 family of standards for exchanging healthcare information electronically. FHIR represents clinical and administrative concepts as resources (Patient, Observation, Encounter, Condition, MedicationRequest, etc.) exposed over a RESTful HTTP API with JSON / XML / Turtle payloads.

First wiki canonicalisation 2026-05-27 in the Databricks + Health Samurai co-marketing post on building a FHIR-native health data platform on Lakebase.

Definition

A FHIR-native data platform stores clinical and administrative data as FHIR resources rather than as proprietary tables, and exposes that data through:

  • RESTful FHIR API — GET /Patient/123, GET /Observation?subject=Patient/123, etc.
  • Standard payload formats — JSON / XML / Turtle.
  • Standard versions — primarily FHIR R4 (current widely-deployed) and FHIR R5 (current).

FHIR sits in the broader HL7 family alongside legacy formats:

Standard Role
FHIR R4 / R5 modern interoperability standard; resource-shaped, REST-friendly
HL7 v2 legacy clinical-message format, pipe-delimited, widely deployed
C-CDA document-based clinical-summary standard
X12 EDI standard primarily for healthcare claims and billing

The 2026-05-27 source argues that legacy formats should be converted into FHIR at point of entry rather than persisted alongside FHIR — Health Samurai ships open-source HL7v2 / C-CDA / X12 converters as the canonical inbound transform.

Code systems FHIR references

FHIR resources reference shared code systems to encode clinical meaning:

  • LOINC — laboratory observations
  • SNOMED CT — clinical terminology (diagnoses, procedures, findings)
  • RxNorm — medications and drug nomenclature
  • ICD-10 — disease and procedure classification

Without a terminology server that normalises codes across vocabularies, the same diagnosis can be counted multiple times under different codes. The 2026-05-27 source verbatim: "A single diagnosis may appear under multiple codes across multiple vocabularies."

Implementation Guides (IGs)

A FHIR resource definition is intentionally generic — a Patient resource can be used in countless contexts. FHIR Implementation Guides narrow the generic resource definitions into use-case-specific conformance contracts:

  • US Core — baseline US-realm interoperability (USCDI alignment).
  • CARIN Blue Button — patient-access claims data.
  • Da Vinci PDex — payer-data exchange.
  • mCODE — minimal Common Oncology Data Elements.

Per the 2026-05-27 source, IGs are how a single FHIR substrate can satisfy multiple regulatory + partner contracts without a per-contract data-model rewrite.

Why FHIR is a substrate not a veneer

The 2026-05-27 source's load-bearing claim is that FHIR is the right shape for the substrate itself, not just an interoperability adapter on top of a proprietary store. The argument:

"Open standards mean ensuring your data model isn't locked into a singular vendor. The same FHIR resources that power interoperability today can support analytics, AI, and future applications without rework. Switching tools shouldn't require re-modeling your data."

If the substrate is FHIR, then:

  • Compliance becomes architectural. CMS-0057 Patient Access Rule, ONC Health IT Certification, Payer-to-Payer data exchange are downstream consequences of building on FHIR rather than separate workstreams.
  • Tool switching doesn't require remodeling. New analytics engines, new AI agents, new EHR integrations all consume the same FHIR resources.
  • The FHIR API is no longer a bottleneck. When FHIR is the substrate, analytical workloads don't have to extract through the FHIR API — they can read the substrate directly via SQL on FHIR ViewDefinitions or via dual-access patterns like Aidbox-on-Lakebase + Moonlink.

Conventional FHIR-server failure mode

Per the 2026-05-27 source, conventional FHIR servers are "designed for transactional use cases — document exchange, point lookups, regulatory APIs — not for the access patterns of modern analytics, ML pipelines, or AI agents that need to scan millions of resources efficiently." This forces a structural choice: over-provision the FHIR server for analytical scan-load, or extract data into a separate warehouse via ETL. Both options carry duplication tax (storage + compute + governance + audit-trail split).

The FHIR-server-on-lakehouse-substrate pattern resolves this by colocating the FHIR server with an analytical substrate that handles scan-heavy workloads natively, with Moonlink doing real-time operational↔analytical sync without customer-managed ETL.

Seen in

Last updated · 542 distilled / 1,571 read