FHIR Implementation Guides Explained: Dependencies, Conformance, and Selection Strategy

A FHIR Implementation Guide (IG) is a structured specification that packages profiles, value sets, code systems, capability statements, example resources, and narrative documentation into a single cohesive, versioned artifact defining how FHIR must be implemented for a given use case or regulatory context. The base FHIR specification is deliberately generic; IGs are where interoperability actually gets specific. They are the primary mechanism through which national authorities, professional bodies, and industry consortia codify their requirements — US Core, the International Patient Summary (IPS), the Da Vinci family, and SMART App Launch are among the most widely referenced IGs in production deployments today [1][2][5]. For an architect, understanding the IG landscape of your target market is a prerequisite for any FHIR-based architecture decision: the IGs, not the base specification, determine what your systems must actually do.

The IG Landscape: Regulation Turns Guides into Requirements

The clearest illustration is the U.S. realm. The ONC's USCDI defines what data must be interoperable, and US Core — a FHIR R4-based IG updated in step with USCDI versions — defines how, through detailed profiles whose lineage traces back to ONC certification criteria [1]. Internationally, the IPS IG specifies how to represent the ISO 27269 patient summary dataset in FHIR: a minimal, non-exhaustive, specialty-agnostic document designed for unplanned cross-border care, which many jurisdictions now use as the starting point for national summaries [2]. Layered on top of realm-level baselines sit use-case IGs — the Da Vinci guides for U.S. payer-provider exchange such as prior authorization, SMART App Launch for app authorization, bulk data for population-level export, and domain IGs for oncology, public health reporting, and more [5].

The Dependency Hierarchy: Conformance Is Transitive

From an architecture standpoint, the critical insight is that IGs form a dependency hierarchy. A national base IG may derive from US Core or IPS, and a use-case IG layers additional constraints on top of the national base. The IPS guide states this model explicitly: jurisdictions are expected to profile based on IPS, and jurisdictional adaptations may add constraints such that every document conforming to the jurisdictional profile inherently conforms to IPS — while IPS documents from elsewhere may not conform to the local profile [2]. Conformance is therefore transitive: satisfying a use-case IG means satisfying every constraint across the entire dependency chain, not just the immediate guide.

This has three practical consequences for architects:

• Map the full chain, not the top of it: Before committing to a program, enumerate every IG in the dependency graph, including the specific versions — IG versions pin base-specification versions and terminology releases, and version skew across the chain is a common source of validation failures.
• Hunt for constraint conflicts early: When two IGs in your program profile the same resource differently — different required bindings on the same element, incompatible slicing, diverging cardinalities — you may be unable to produce a single instance conforming to both. In our experience this surfaces late, during integration testing, unless someone deliberately diffs overlapping profiles during architecture review.
• Trust tested conformance, not claimed conformance: A vendor's "supports US Core" or "IPS-ready" claim is meaningful only when backed by verifiable test results. In the U.S., the Inferno ONC Certification (g)(10) Standardized API Test Kit is an approved test method for the § 170.315(g)(10) certification criterion, exercising SMART App Launch flows, US Core profile conformance, and bulk data export [3]; Touchstone plays a comparable role for many other IG test programs. Ask for the test results, not the brochure.

Authoring and Governance: The IG Is a Living Product

The IG authoring toolchain centers on the FHIR IG Publisher, which takes FSH or raw JSON/XML source and produces both the human-readable HTML publication — hosted on hl7.org/fhir or a custom domain — and the machine-readable NPM package (package.tgz) that validators, servers, and downstream IGs consume as a dependency [4]. That dual output is the point: an IG is simultaneously documentation for humans and a computable dependency for tooling, which is why version management matters as much as content.

Effective IG governance requires a clear profiling governance process, semantic versioning discipline, and — above all — a feedback loop with implementers. In our experience, IGs developed without implementer input frequently contain constraints that are technically valid but practically unmeetable: mandatory elements that source systems cannot reliably populate, terminology bindings that assume licensing not all participants hold, or must-support expectations no one budgeted to test. Balloting and connectathon cycles exist precisely to catch these before publication.

An IG Selection Framework for Multi-Program Ecosystems

For architects designing a FHIR ecosystem that must serve multiple programs, we suggest evaluating candidate IGs along four dimensions: regulatory force (is the IG mandated, referenced, or merely fashionable in your market?), dependency compatibility (does it share a base with the IGs you already implement, or does it drag in a conflicting chain?), maturity and tooling (is there a published version with a test kit — Inferno [3], Touchstone — or only a CI build?), and implementation cost (which constraints require data your systems don't capture today?). The healthiest architectures treat the base IG as part of their canonical data contract and isolate use-case IGs behind program-specific facades, so a new program means a new layer — not a re-plumbing of the core.

Where CaboLabs Fits

Mapping IG dependency chains, resolving profile conflicts, and proving conformance is specialized work that sits between standards expertise and engineering — exactly where CaboLabs operates. We help health systems, vendors, and national programs select and implement FHIR Implementation Guides, author custom IGs and profiles with governed FSH/IG Publisher pipelines, and validate conformance before certification testing does it for you. And for architectures where FHIR IGs govern the exchange layer, our openEHR-native clinical data repository Atomik provides the standards-based persistence layer beneath it — keeping your clinical data in a vendor-neutral model while your FHIR facades track evolving IG versions.

If you're selecting IGs for a new program, untangling conformance conflicts across a dependency chain, or preparing for certification testing, talk to us at cabolabs.com — we'll help you build a FHIR ecosystem that conforms by design, not by patchwork.