- The FHIR R4 base specification defines the shapes of health data but leaves almost every field optional, because one standard must serve dozens of countries.
- US Core is the implementation guide that turns base FHIR into house rules for American clinical data: which profiles, which must-support fields, which terminologies.
- US Core versions track USCDI, the federal list of data classes certified systems must exchange; US Core 6.1.0 aligns with USCDI v3.
- A vendor that claims US Core support without naming a version number has said very little — must-support lists and bindings change between releases.
- Pinning exact versions is what makes validation reproducible and audits answerable years later; upgrades should be deliberate migrations, not silent drift.
On this page
Pull your record from two different hospital portals and lay the files side by side. Both are valid FHIR. One Patient resource carries your birth date, your language, your race and ethnicity coded to federal standards. The other carries a name and an identifier and nothing else. One codes your diagnosis in SNOMED CT; the other uses a billing code wrapped in a local extension.
Both systems speak FHIR, fluently. Neither understands the other. The gap between those two files is the entire reason US Core exists.
A base standard is a dictionary, not a conversation
The FHIR R4 base specification defines about 145 resource shapes — Patient, Condition, Observation, MedicationRequest — and the API for moving them, but it deliberately leaves almost every field optional. This is not an oversight. One standard has to serve Dutch general practice, Japanese hospital billing, and a US oncology clinic at the same time, and the only way to do that is to specify structure while staying agnostic about content.
The result is a dictionary and a grammar, not a conversation. Base FHIR guarantees that a Patient resource will be shaped like a Patient resource. It does not guarantee that the fields you need will be filled in, or that two systems will code the same fact the same way. (For the longer story of where FHIR came from and why it won, see What is FHIR?)
What an implementation guide does
An implementation guide is a rulebook layered on the base standard for one community of use. Its main tool is the profile: a constrained version of a base resource that says which fields are required, which terminologies are allowed, and how repeating elements must behave.
Profiles also introduce the quietly powerful idea of must-support. A must-support element is not always mandatory — a patient with no recorded allergies has no allergy to send — but a system must be capable of handling it: if the data exists, the sender must include it, and the receiver must process it without breaking. Must-support is the difference between a standard that describes data and one that obligates systems.
The analogy that holds up: the base spec is the dictionary and grammar of a language; an implementation guide is the house style of a publication written in it. Same words, far fewer arguments.
US Core: the house rules for American health data
US Core is the HL7 implementation guide that tells US systems exactly how to use FHIR R4 for routine clinical data. It grew out of the Argonaut Project, an industry sprint launched in 2014 by major EHR vendors and providers who wanted FHIR usable in American production systems faster than the formal standards cycle would deliver.
US Core profiles cover the everyday substance of a chart: patients, conditions, lab results, vital signs, medications, immunizations, allergies, procedures, clinical notes. For each one it names required fields, must-support fields, and terminology bindings — lab Observations coded in LOINC, medications in RxNorm, problems in SNOMED CT, vocabularies distributed in the US through the National Library of Medicine. How those vocabularies divide up medicine is its own story, told in SNOMED, LOINC, ICD-10, RxNorm: decoded.
Its gravity comes from regulation. The 21st Century Cures Act led to certification rules requiring patient-access APIs, and the certification criterion for those APIs — known in the trade as (g)(10) — requires conformance to US Core. When your portal hands your records to an app, the shape of what arrives is US Core.
Version numbers are load-bearing
US Core is not one thing; it is a sequence of releases, each aligned to a version of USCDI — the United States Core Data for Interoperability, the federal list of data classes certified systems must be able to exchange. US Core 6.1.0 aligns with USCDI v3. Each release adds profiles, changes must-support lists, and tightens or relaxes bindings.
| Layer | What it is | What it pins down |
|---|---|---|
| FHIR R4 | Base standard | Resource shapes, data types, the API itself |
| US Core 6.1.0 | Implementation guide | Which profiles apply, must-support fields, terminology bindings |
| USCDI v3 | Federal policy list | Which classes of data must be exchangeable at all |
This is why a vendor saying "we support US Core" has told you almost nothing. Two systems on different US Core versions will disagree — politely, silently — about which fields matter and which codes count. The number is the claim.
Why a platform pins exact versions
Pinning versions is what makes validation mean something over time. Consider the research scenario: a cohort is assembled in 2026 from records validated on ingest. In 2032, an auditor — or a regulator, or the patient — asks how a record qualified. If validation targeted "the latest US Core," the honest answer is: it depends when you asked. A record that passed yesterday can fail today without a single byte of it changing.
A pinned target removes the ambiguity. Every record is validated against the same fixed ruleset; the ruleset is named in the audit record; an upgrade to a newer US Core version is a deliberate, recorded migration rather than ambient drift. Validation becomes a fact with a timestamp instead of an opinion with a shelf life — the same property that makes append-only audit trails worth keeping for six years.
Mithras Health is built on exactly this discipline. FHIR R4 with US Core 6.1.0 profiles is the system of record: every record is validated against those pinned profiles on ingest, and the OMOP views researchers query are projections from that validated truth — a division of labor we unpack in FHIR vs. OMOP. When US Core moves to a new version, the platform migrates on purpose, and the migration is itself an event on the audit spine.
The deeper lesson travels beyond healthcare. Standards earn trust the way contracts do — not by being beautifully written, but by naming their versions and meaning them. A profile you can quote, with a number you can check, is worth a hundred assurances of compatibility.
Appendix · questions
Questions, answered
What is the difference between FHIR and US Core?
What does must-support mean in US Core?
What is USCDI and how does it relate to US Core?
Why does Mithras Health pin US Core 6.1.0 specifically?
The patient-mediated research-data platform for chronic disease — 28 conditions, worldwide consented sources, one auditable spine. Join the launch list.
The sun is rising on chronic-disease research.
One email when we launch — and nothing else. Patients, researchers, sponsors, and programs all start here.