What does implementing US Core actually require?
"We support FHIR R4" and "we support US Core" are not the same claim, and the gap between them is where certification and real integrations succeed or fail. US Core is the set of FHIR profiles that turn generic R4 resources into the specific, constrained shapes US systems must exchange. This guide explains US Core, its relationship to USCDI, the must-support obligation that trips up most teams, and how to implement it so you pass conformance testing.
US Core, USCDI, and how they relate
USCDI (United States Core Data for Interoperability) is the government-defined list of data classes and elements that must be exchangeable — things like patient demographics, problems, medications, allergies, labs, and clinical notes. US Core is the FHIR implementation guide that says how to represent those USCDI elements as constrained FHIR R4 profiles. In short: USCDI is the what, US Core is the how.
Because ONC certification references specific USCDI versions, US Core is versioned to match. Supporting "US Core" without naming the version is meaningless — you must state (and test against) the exact version, e.g. US Core aligned to the USCDI version your certification requires.
Profiles: the heart of US Core
A US Core profile constrains a base resource. US Core Patient, for example, requires an identifier, a name, and specific extensions for race, ethnicity, and birth sex — constraints the base FHIR Patient does not impose. Implementing US Core means implementing dozens of these profiles across resources like Patient, Condition, Observation (with several lab/vitals variants), MedicationRequest, AllergyIntolerance, DocumentReference, and more.
Must-support: the obligation that fails certification
Every US Core profile marks certain elements as must-support. Must-support has a precise meaning that teams routinely get wrong:
- As a server: if you have the data for a must-support element, you must be able to populate it in the response. You cannot silently drop it.
- As a client: you must be able to process (display or store) must-support elements without error, even ones you don't specialize in.
- Must-support is not the same as "required (min=1)". An element can be must-support but optional — the obligation is about capability, not always presence.
The common failure is a server that models the data internally but never surfaces a must-support element, or a client that chokes on an element it didn't expect. Conformance tools test exactly this.
Terminology bindings you can't hand-wave
US Core binds many elements to specific code systems — LOINC for labs and vitals, SNOMED CT for problems, RxNorm for medications, CVX for immunizations, ICD-10-CM where applicable. Implementing US Core means your data actually carries these codes, not free text. Mapping legacy or proprietary codes to the required systems is usually the largest piece of the work.
A practical implementation path
- Scope to the exact USCDI/US Core version your certification or partner requires, and enumerate the profiles in play.
- Map your source data to each profile element, resolving terminology to LOINC/SNOMED/RxNorm/CVX up front.
- Implement the required US Core search parameters and _include behavior — certification tests search, not just read.
- Validate continuously against the US Core package and run Inferno (the ONC conformance suite) in CI, not at the end.
- Handle must-support explicitly on both server and client paths.
Why this is worth doing well
US Core is the difference between a FHIR endpoint that technically returns JSON and one that a certified EHR, a payer, or a national network will actually trust and consume. Getting the profiles, must-support, and terminology right is what makes your data genuinely interoperable rather than merely FHIR-shaped.
