Implementation Guides and US Core

From a profile to a publishable package

A single profile is a useful artifact, but a real-world exchange is never one profile. It is a set of profiles that reference each other, the extensions those profiles pull in, the value sets their coded elements bind to, worked examples implementers can validate against, and prose explaining how the pieces fit and what a server must do. Shipping those as loose files leaves every implementer to assemble — and reassemble — the same context.

An Implementation Guide (IG) is the unit that solves this. It is a coherent, versioned, published package built for a specific use case that bundles profiles, extensions, value sets, examples, and human-readable narrative into one deliverable, telling implementers exactly which resources to build and which constraints to honor. The generic mechanics of an IG — how this collection is itself represented and published in FHIR — are described by the ImplementationGuide resource and its tooling ¹. An IG is the FHIR analogue of a v2 implementation guide: the same role of pinning down an open standard for a concrete exchange, expressed in FHIR’s own machinery rather than in narrative tables alone.

The key shift from the previous lesson is one of scope. There you constrained one resource with a StructureDefinition. An IG packages many such constraints together so that “conform to this exchange” becomes a single, citable target instead of a scavenger hunt across separate profiles.

US Core: the US-Realm baseline

The most important IG to know in the United States is the HL7 US Core Implementation Guide. Built on FHIR R4, it defines the minimum conformance requirements for accessing patient data in the US Realm — the floor that systems exchanging US patient data are expected to meet ². It is deliberately a baseline, not a ceiling: it specifies what every conforming system must be able to do, leaving room for narrower IGs to add more.

Because it is the baseline, US Core also functions as a foundation that other US-Realm IGs build on. The governing convention is that a US-Realm IG SHALL use the relevant US Core profiles where they apply, or explicitly state why it cannot ². This is what keeps the US FHIR ecosystem coherent: a more specialized IG for, say, a particular clinical domain inherits US Core’s Patient profile rather than inventing a competing one, so a system that already supports US Core has a running start on every IG layered above it.

How US Core relates to USCDI

US Core does not define which data must be exchangeable from scratch. That comes from USCDI, the United States Core Data for Interoperability, which enumerates at a high level the data classes and data elements that must be available for exchange. USCDI is a policy-level list — it names the data, not its wire format.

US Core supplies the missing half: the concrete FHIR representation. For each USCDI data element, US Core provides the FHIR profiles that satisfy it, specifying which elements, extensions, vocabularies, and value sets a conforming instance and system must support ². In other words, USCDI says what, and US Core says exactly how, in FHIR. Because the two are coupled, US Core is revised on roughly an annual cycle to track new USCDI versions, so the IG version an implementer targets matters as much as the fact that they target US Core at all.

This is also where the previous lesson pays off directly: US Core profiles are profiles in the precise sense already covered. They tighten base R4 resources, layer in extensions, bind coded elements to value sets, and lean heavily on Must Support to oblige systems to handle the USCDI-mandated elements when present — without claiming any particular element list here that the IG itself must be consulted to confirm.

Why this is the practical definition of “FHIR support”

US Core matters far beyond HL7 because it sits underneath US regulatory expectations for health-data API access, including the patient-access APIs that certified systems must expose. Regulation points at USCDI for the data, and US Core is the FHIR expression that operationalizes it. The practical consequence is that in the US, claiming “we support FHIR” means very little on its own — the meaningful claim is “we support US Core,” at a stated version, because that is what determines whether two systems can actually exchange the expected patient data.

That framing sets up the rest of this course. Conforming to US Core is not a matter of opinion: an instance either satisfies the profiles or it does not, and a system either supports the required elements or it does not. Turning that “either/or” into an automatic, repeatable check is the job of validation, which the next lessons take up — running instances against the profiles US Core publishes and reporting precisely where conformance breaks down.