Skip to content

CONCEPT Cited by 1 source

FHIR Implementation Guide

A FHIR Implementation Guide (IG) narrows generic FHIR resource definitions into a use-case-specific conformance contract by adding profiles (constraints on resource shapes), value-set bindings (which code systems are allowed for which fields), examples, and operational rules. IGs are how a single FHIR substrate can satisfy multiple regulatory + partner contracts simultaneously without a per-contract data-model rewrite.

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 resource definition (e.g. Patient) is intentionally generic — it can be used in countless contexts. An IG narrows that:

  • Profiles — constrain a resource shape (e.g. US Core Patient requires identifier, name, gender, birthDate).
  • Value-set bindings — specify which terminology code systems can be used for a given coded field (e.g. US Core Condition binds code to ICD-10 / SNOMED CT).
  • Extensions — define custom fields beyond the base resource for use-case needs.
  • Operational rules — e.g. how Patient.identifier should be populated for a specific regulatory contract.

A FHIR engine that supports IGs can validate resources against an IG at point of entry — rejecting non-conformant resources before they enter the substrate, rather than discovering conformance gaps during downstream use.

Named IGs (2026-05-27 disclosure)

The source enumerates four IGs as exemplars Health Samurai's standardisation layer supports:

IG Purpose
US Core Baseline US-realm interoperability; alignment with USCDI
CARIN Blue Button Patient-access claims data exchange
Da Vinci PDex Payer-data exchange (between insurance payers)
mCODE Minimal Common Oncology Data Elements

Verbatim from the source: "Conformance to specific use cases is defined through FHIR Implementation Guides like US Core, CARIN Blue Button, Da Vinci PDex, and mCODE — with additional code systems and IGs incorporated as regulations and partner requirements evolve."

Architectural role

In the FHIR-server-on-lakehouse-substrate pattern (Aidbox-on-Lakebase + Moonlink + Unity Catalog), IGs play the point-of-entry validation role:

"FHIR Implementation Guides and Validation enforce data quality and conformance at the point of entry — not after the fact."

This is structurally important because once data lands in the substrate non-conformantly, downstream conformance becomes a remediation problem (reprocess, backfill, schema migration) rather than a policy problem. IG-level validation at point of entry pushes conformance to the boundary.

The pluggability of IGs is also load-bearing: as regulations evolve (CMS-0057, ONC certification, Patient Access Rule, Payer-to-Payer Data Exchange), new IGs can be added without re-modelling the substrate, "with additional code systems and IGs incorporated as regulations and partner requirements evolve."

Seen in

Caveats

  • Capability altitude only. No specific profile examples, no value-set binding walkthroughs, no extension mechanism disclosure, no validation engine internals.
  • No version pinning. Which IG versions, which FHIR R4 vs R5 alignment, not disclosed.
  • No profile-conflict resolution disclosure. When a resource needs to satisfy multiple IGs (e.g. US Core + mCODE), how conflicts are resolved is not addressed in the source.
Last updated · 542 distilled / 1,571 read