Ask three people what “FHIR” means and you may get three answers, all partly right. For Arizona providers trying to make sound decisions about integrations and patient-access apps, the confusion is costly. This explainer separates the three layers people routinely conflate — FHIR, US Core, and USCDI — and describes what each actually obligates.
Layer one: FHIR R4, the standard
Fast Healthcare Interoperability Resources (FHIR) is HL7’s standard for representing and exchanging clinical data. Release 4 (R4) is the widely deployed version and the first to carry normative content, meaning its foundational parts come with a backward-compatibility commitment. FHIR organizes information into resources — a Patient resource, an Observation resource, a MedicationRequest resource — each a well-defined data structure, exchanged over a RESTful web API. FHIR by itself is flexible to the point of being underspecified for any one country’s needs; that flexibility is intentional.
Layer two: US Core, the U.S. profile set
Because raw FHIR is so flexible, two conformant systems can still fail to understand each other. US Core is the HL7 implementation guide that constrains FHIR resources for the United States — specifying which fields must be present, which code systems and value sets apply, and which API interactions a server should support. When a vendor says they “support US Core,” they are claiming their FHIR endpoints behave in this expectable, profiled way. That is the layer that makes integration practical rather than theoretical.
Layer three: USCDI, the data list
The U.S. Core Data for Interoperability (USCDI) is the list of data elements that systems are expected to be able to exchange — demographics, problems, medications, lab results, and more. US Core is the FHIR-shaped container; USCDI is the content the container must be able to carry. USCDI expands on an annual cadence, and US Core releases track it.
What this means in practice
When you evaluate a product or plan an integration in Arizona, ask three specific questions instead of “does it do FHIR”:
- Which FHIR version? R4 is the practical baseline.
- Which US Core version does it conform to? This tells you how predictably its endpoints behave.
- Which USCDI version’s data does it support? This tells you what you can actually get out of it.
Those three answers, taken together, describe real capability far better than the single word “FHIR.” For deeper plain-language coverage, see our Standards work area, and for the broader exchange picture, our Network coverage. Definitions for every acronym here live in the glossary.