Written and maintained by CASRAI Editorial Board
Last updated
US Core FHIR (formally the HL7 FHIR® US Core Implementation Guide, canonical URL http://hl7.org/fhir/us/core) is the foundational national interoperability specification developed by the HL7 International US Realm Steering Committee and the Argonaut Project to constrain the base HL7 Fast Healthcare Interoperability Resources (FHIR) Release 4 (R4, v4.0.1) standard for United States healthcare data exchange. Because the international base FHIR R4 specification is intentionally permissive—leaving most elements optional (0..1 or 0..*) and allowing jurisdiction-neutral code systems—two EHR systems implementing unprofiled base FHIR R4 cannot reliably exchange clinical records without bilateral custom mapping.
The US Core Implementation Guide resolves this ambiguity by defining the minimum mandatory constraints on FHIR R4 resources—including required cardinalities, US-specific extensions (such as OMB race, ethnicity, tribal affiliation, and birth sex), mandatory terminology bindings (SNOMED CT US Edition, LOINC, RxNorm, ICD-10-CM, CPT, and CVX), and required RESTful search parameter combinations—that translate the Office of the National Coordinator for Health Information Technology (ONC) United States Core Data for Interoperability (USCDI) policy catalog into executable, testable APIs under federal regulation (45 CFR § 170.315(g)(10) and 45 CFR § 170.215).
What Is US Core FHIR and How Does It Relate to ONC USCDI?
A common misconception in clinical informatics is treating USCDI and US Core FHIR as synonymous. In the federal health IT regulatory stack, they operate at two distinct layers:
- ONC USCDI (Semantic Policy Layer, 45 CFR § 170.213): Maintained by ONC (now ASTP/ONC), USCDI is a standard-agnostic taxonomy of Data Classes (e.g., Allergies and Intolerances, Clinical Notes, Laboratory, Medications, Problems, Vital Signs) and Data Elements (e.g., Patient Demographics—First Name, Date of Birth, Sexual Orientation, Social Determinants of Health Assessment). USCDI specifies what clinical concepts must be exchanged, whether serialized in HL7 C-CDA XML or HL7 FHIR JSON.
- HL7 FHIR US Core Implementation Guide (Technical Wire Specification, 45 CFR § 170.215): Maintained by HL7 International, US Core is the concrete FHIR R4 machine-readable implementation guide (composed of
StructureDefinition,ValueSet,CodeSystem,SearchParameter, andCapabilityStatementartifacts) that specifies how every USCDI data element is represented in JSON/XML and queried over HTTPS via RESTful APIs.
US Core Version Alignment: STU 3.1.1, STU 6.1.0, and STU 7.0.0
Each major ballot of the US Core Implementation Guide is designed to implement a specific version of ONC USCDI. Under the ONC 21st Century Cures Act Final Rule and the Health Data, Technology, and Interoperability (HTI-1) Final Rule, certified health IT developers must upgrade their standardized patient and population APIs (45 CFR § 170.315(g)(10)) according to a strict federal regulatory timeline:
| US Core IG Version | Aligned USCDI Version | Base FHIR Release | ONC Regulatory Status & Compliance Deadline | Key New Profiles & Technical Additions |
|---|---|---|---|---|
| US Core STU 3.1.1 | USCDI v1 | FHIR R4 (4.0.1) | Original Cures Act baseline (December 31, 2022 mandate; expiring December 31, 2025) | 26 core profiles including US Core Patient, AllergyIntolerance, CarePlan, CareTeam, Condition, Device, DiagnosticReport, DocumentReference, Encounter, Goal, Immunization, MedicationRequest, Observation (Lab, Pediatric Vitals, Smoking Status), Organization, Practitioner, Procedure, Provenance |
| US Core STU 4.0.0 & STU 5.0.1 | USCDI v1 / v2 | FHIR R4 (4.0.1) | Voluntary SVAP (Standards Version Advancement Process) approved versions | Added SDOH Assessment/Condition/Goal/Intervention profiles, ServiceRequest, QuestionnaireResponse, and RelatedPerson; split Vital Signs into base FHIR profiles |
| US Core STU 6.1.0 | USCDI v3 | FHIR R4 (4.0.1) | HTI-1 Mandatory Baseline (Required across all certified EHRs by January 1, 2026; 45 CFR § 170.215(b)(1)(ii)) | Expands to 40+ profiles: adds US Core Coverage, Specimen, MedicationDispense, Observation Clinical Result, Screening/Assessment, Pregnancy Status/Intent, Sexual Orientation, Gender Identity, Tribal Affiliation, and Condition Problems/Health Concerns vs. Encounter Diagnosis split |
| US Core STU 7.0.0 | USCDI v4 | FHIR R4 (4.0.1) | Published May 2024; SVAP / HTI-2 regulatory progression | Adds US Core Location, Treatment Intervention Preference, Care Experience Preference, Average Blood Pressure, and Substance Use/Alcohol Status profiles |
Core Technical Architecture: Profiles, Extensions, and Terminology Bindings
Every US Core profile constrains a base FHIR R4 resource and serves as the parent profile for downstream specialty implementation guides (such as HL7 Da Vinci payer-provider IGs, CARIN Blue Button, and mCODE for oncology). Key architectural patterns include:
- US Core Patient Profile (FHIR Patient): Requires at least one patient
identifier(such as a Medical Record Number, MRN), at least onename(family and/or given), and administrativegender. Because base FHIR R4 omits race and ethnicity (which are illegal to collect in several European jurisdictions), US Core defines complex extensions:us-core-raceandus-core-ethnicity(bound to CDC/OMB Race and Ethnicity Category codes plus detailed concepts),us-core-birthsex,us-core-tribal-affiliation, andus-core-sex(in STU 6.1.0+). - US Core Condition Profiles (FHIR Condition): Starting in US Core STU 5.0.1 and mandatory in STU 6.1.0, US Core split the single Condition profile into two distinct profiles: US Core Condition Problems and Health Concerns Profile (category
problem-list-itemorhealth-concern, including SDOH conditions) and US Core Condition Encounter Diagnosis Profile (categoryencounter-diagnosis). Both bindCondition.codeto SNOMED CT (preferred) and ICD-10-CM (extensible backup). - US Core Clinical Notes and Diagnostic Reports (FHIR DocumentReference): Unstructured and semi-structured clinical notes (Consultation Note, Discharge Summary, History & Physical, Imaging Narrative, Laboratory Report Narrative, Pathology Report Narrative, Procedure Note, and Progress Note) are exchanged via
US Core DocumentReference(indexed by LOINC document type codes), whereas structured discrete panels and cardiology/radiology reports also exposeUS Core DiagnosticReportfor Laboratory Results and Report/Note Exchange.
Understanding MustSupport, Missing Data, and Mandatory Search Parameters
In US Core StructureDefinitions, data elements marked with the crimson S (MustSupport = true) flag govern how ONC-certified servers (US Core Responders) and client applications (US Core Requestors) are tested by the ONC Inferno certification test kit:
- US Core Responder (EHR Server) Rules: If the underlying EHR database captures a
MustSupportelement for a patient, the FHIR server must populate that element in the returned resource instance.- Missing Optional Elements (Min Cardinality =
0): If the EHR does not have data for aMustSupportelement whose minimum cardinality is0(e.g.,Patient.telecomorMedicationRequest.dosageInstruction), the server simply omits the element from the JSON output. - Missing Required Elements (Min Cardinality ≥
1): If the EHR lacks data for a requiredMustSupportelement (min cardinality1), the server cannot omit it without violating schema validation. Instead, for coded elements with extensible/preferred/example bindings, the server sends the appropriate “unknown” concept from the value set or attaches the HL7data-absent-reasonextension (http://hl7.org/fhir/StructureDefinition/data-absent-reason) with codeunknownormasked.
- Missing Optional Elements (Min Cardinality =
- US Core Requestor (Client App) Rules: The client application must be capable of parsing every
MustSupportelement—including slices and `data-absent-reason` extensions—and displaying it for human clinical use or storing it for downstream analytics without throwing an exception or suppressing clinical context. - Mandatory Search Parameter Combinations: Every US Core profile specifies
SHALLandSHOULDRESTful search parameters. For example, a compliant US Core Responder must support queryingObservationLaboratory Results byGET [base]/Observation?patient=[id]&category=http://terminology.hl7.org/CodeSystem/observation-category|laboratoryas well as combined date-range and LOINC code searches (patient + category + dateandpatient + code), and must support returningProvenancerecords via_revinclude=Provenance:target.
Frequently Asked Questions
What is US Core FHIR?
US Core FHIR (the HL7 FHIR US Core Implementation Guide) is the national set of FHIR Release 4 profiles, extensions, terminology bindings, and RESTful search rules that define the minimum interoperability requirements for exchanging electronic health information in the United States. It serves as the technical specification for ONC’s USCDI standard under federal certification rule 45 CFR § 170.315(g)(10).
What is the difference between US Core STU 3.1.1 and US Core STU 6.1.0?
US Core STU 3.1.1 implements USCDI v1 (26 profiles) and served as the initial 21st Century Cures Act certification baseline. US Core STU 6.1.0 implements USCDI v3 (over 40 profiles), adding health insurance coverage (Coverage), laboratory specimens (Specimen), pharmacy dispenses (MedicationDispense), social determinants of health (SDOH) assessments, pregnancy status, sexual orientation, gender identity, and separate profiles for problem-list conditions versus encounter diagnoses. Under the ONC HTI-1 Final Rule, certified health IT systems must transition to US Core STU 6.1.0 by January 1, 2026.
How is US Core FHIR used in clinical research?
In clinical research and real-world data (RWD) studies, US Core FHIR provides a standardized API layer that allows electronic data capture (EDC) platforms, clinical trial registries, and patient-mediated SMART on FHIR research apps to extract harmonized demographics,SNOMED/ICD-10 diagnoses, LOINC laboratory results, and RxNorm medications across Epic, Oracle Health, MEDITECH, and ambulatory EHRs without building site-specific HL7 v2 interfaces, and maps directly to CDISC SDTM domains via the HL7 Vulcan EHR-to-EDC implementation guides.
