FHIR, USCDI, and US Core: What They Are, How They Fit

FHIR says how to send data. USCDI says what data. US Core says exactly how to format it. Here's how the three standards fit together.

the nighthawk · 12 min read · 2026-03-31

Most teams start their healthcare integration journey by Googling "what is FHIR." They find the spec, read about Resources and RESTful APIs, and think they understand the landscape. Then they hit a compliance requirement that mentions USCDI v3, and suddenly there are three acronyms that all seem to mean "healthcare data standard" but aren't the same thing.

They answer three different questions. Confusing them costs teams months of rework. Here's the 101.

FHIR Is the Envelope

FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for exchanging healthcare data. It defines approximately 150 resource types — Patient, Observation, Condition, MedicationRequest, Encounter, and so on — and specifies how to send them over RESTful APIs using JSON or XML.

If you've built a REST API before, FHIR will feel familiar. Resources have IDs. You GET them, POST them, PUT them, DELETE them. You search with query parameters. Authentication uses OAuth2. The payload is JSON. It's modern web architecture applied to healthcare data. (This is genuinely one of the better-designed healthcare standards — damning with faint praise, maybe, but credit where it's due.)

FHIR follows an 80/20 design principle. The base resource definitions cover the common cases — the fields that most systems need most of the time. For the remaining 20%, FHIR provides profiles (constraints that tighten the base definition) and extensions (additional fields for domain-specific data). This keeps the core spec manageable while allowing customization for domain-specific needs.

Here's what FHIR is not:

• Not a content standard. FHIR defines the shape of an Observation resource. It does not say which observations you must support or which code systems to use.
• Not a database schema. FHIR resources are wire formats for exchange. How you store data internally is your business.
• Not plug-and-play. Two systems that both "support FHIR" can be completely incompatible. One might put lab results in Observation; the other might use DiagnosticReport. Both are valid FHIR.
• Not a security protocol. FHIR defines data formats and API patterns. Authentication and authorization are handled by SMART on FHIR, a separate specification.

The key analogy: FHIR defines the shape of the envelope and the postal routes. It doesn't tell you what letter to put inside.

One more thing on versions: FHIR R4 is the version that matters. The 21st Century Cures Act and ONC regulations mandate FHIR R4 APIs. R5 was published in 2023 and has useful improvements (particularly to Subscriptions), but vendor adoption is minimal. R6 is in ballot. For regulatory compliance and real-world integration, R4 is the target.

USCDI Is the Required Letter

USCDI (United States Core Data for Interoperability) is defined by ONC — the Office of the National Coordinator for Health IT (now ASTP), a federal agency within HHS. It is not an HL7 product. It is a government specification.

USCDI answers a fundamentally different question than FHIR. Where FHIR asks "how do you send data?", USCDI asks "what data must you be able to exchange?"

Critically, USCDI is technology-agnostic. It applies whether you're using FHIR, C-CDA, HL7v2, or carrier pigeon. It defines data classes and data elements — categories like "Medications" and specific elements like "medication name (RxNorm)." It doesn't care about the wire format.

USCDI Versions

USCDI v3 is the version that matters right now. The HTI-1 final rule made it mandatory as of January 1, 2026 for certified health IT. If you're building toward certification or exchanging data with certified systems, USCDI v3 is your compliance target.

What's In USCDI v3

USCDI v3 organizes data into data classes (broad categories) and data elements (specific items within each class). The data classes include:

• Patient Demographics — name, date of birth, sex, race, ethnicity, address, phone, email
• Allergies and Intolerances — substance, reaction, severity
• Conditions — active problems and health concerns (SNOMED CT coded)
• Medications — active medications with dose, frequency, route (RxNorm coded)
• Laboratory — test results with LOINC codes, reference ranges, interpretation, units
• Vital Signs — blood pressure, heart rate, temperature, BMI, O2 saturation
• Clinical Notes — discharge summaries, progress notes, consultation notes, and more
• Immunizations — vaccine type (CVX coded), date, site, route
• Procedures — CPT or SNOMED coded
• Health Insurance Information — coverage type, payer, member ID (new in v3)
• Health Status/Assessments — functional status, disability status, mental health screening results (new in v3)

The Terminologies

USCDI doesn't just say "exchange lab results." It says how to encode them:

This catches people off guard. USCDI mandates specific ontologies for each data element. If your system stores conditions as free text or proprietary codes, you're not USCDI-compliant regardless of how well your FHIR API works. Ask anyone who's tried to map a legacy system's condition codes to SNOMED — it's a months-long project.

US Core Is the Form Template

So FHIR gives you the envelope. USCDI tells you what letter to put inside and which language to write it in. But there's still a gap: how exactly do you fill out the FHIR resources to satisfy USCDI requirements?

That's what US Core does.

US Core is an HL7 FHIR Implementation Guide (IG) that translates USCDI data requirements into concrete FHIR profiles. A profile takes a base FHIR resource and constrains it: making optional fields required, binding fields to specific code systems, and flagging elements as must-support (meaning your system must be able to store, display, and exchange them even if they're not always populated).

For example, USCDI says "exchange medications using RxNorm." US Core translates that into the US Core MedicationRequest profile, which specifies:

• status is required
• intent is required
• medication[x] must use RxNorm codes (bound to a specific value set)
• subject must reference a US Core Patient
• authoredOn is must-support
• dosageInstruction is must-support
• requester is must-support

Without US Core, two teams implementing "FHIR + USCDI" could produce completely different resource structures and still technically be compliant with both specs independently. US Core eliminates that ambiguity.

Version Mapping

US Core 6.1.0 is the version that implements USCDI v3, which is mandatory as of January 2026. If you're building for compliance today, that's your target IG.

How They Stack Together

Here's the layer cake:

┌──────────────────────────────────────────────┐
│  USCDI v3 (ONC / ASTP)                       │
│  "Exchange lab results with LOINC codes"      │
│  WHAT data  +  WHICH vocabularies             │
├──────────────────────────────────────────────┤
│  US Core 6.1.0 (HL7)                         │
│  "Observation.code must be LOINC,             │
│   Observation.referenceRange required, ..."   │
│  HOW to structure it in FHIR                  │
├──────────────────────────────────────────────┤
│  FHIR R4 (HL7)                                │
│  GET /Observation?patient=123                  │
│  THE transport protocol                       │
└──────────────────────────────────────────────┘

A Concrete Example: Hemoglobin Lab Result

Walk through all three layers for a single hemoglobin A1c lab result:

USCDI v3 says: "Lab results must be exchangeable. Test names use LOINC. Results must include value, units, reference range, and interpretation."

US Core 6.1.0 says: "Use the US Core Laboratory Result Observation profile. Observation.code must come from the LOINC value set. Observation.value[x] is must-support. Observation.referenceRange is must-support. Observation.interpretation is must-support."

FHIR R4 says: "Here's how to encode it as JSON and serve it from a RESTful endpoint."

The result, satisfying all three layers:

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/observation-category",
      "code": "laboratory"
    }]
  }],
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "4548-4",
      "display": "Hemoglobin A1c/Hemoglobin.total in Blood"
    }]
  },
  "subject": { "reference": "Patient/123" },
  "effectiveDateTime": "2026-03-01",
  "valueQuantity": {
    "value": 7.2,
    "unit": "%",
    "system": "http://unitsofmeasure.org",
    "code": "%"
  },
  "referenceRange": [{
    "low": { "value": 4.0, "unit": "%" },
    "high": { "value": 5.6, "unit": "%" }
  }],
  "interpretation": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
      "code": "H",
      "display": "High"
    }]
  }]
}

Every field in that resource serves a purpose defined by one of the three layers. Remove referenceRange and you violate US Core. Change the LOINC code to a proprietary code and you violate USCDI. Change the JSON structure and you violate FHIR. All three layers work together.

How New Standards Get Built: The Gravity Project

So you have the three-layer model: FHIR is the protocol, USCDI says what data to exchange, US Core says how to format it. But where do the requirements come from? How does a new data domain go from "we should standardize this" to "it's legally mandated"?

The Gravity Project is the best example of this pipeline in action. It's worth understanding not just for the SDOH content, but because it shows you exactly how the standards machine works.

Step 1: Identify the gap

Healthcare doesn't happen in a vacuum. A patient's health outcomes are shaped as much by where they live, what they eat, and whether they can get to their appointments as by the medications they're prescribed. These are Social Determinants of Health (SDOH) — food insecurity, housing instability, transportation access, financial strain, social isolation, interpersonal violence, education, employment.

Before Gravity, there was no standard way to represent any of this in clinical data. Every health system that tracked SDOH used different codes, different screening tools, different data structures. A food insecurity screening result from one system was meaningless to another.

Step 2: Form an HL7 FHIR Accelerator

HL7 runs a program called FHIR Accelerators — industry collaborations that bring together stakeholders (providers, payers, vendors, government agencies, patients) to build consensus around a specific domain. Gravity launched in 2019 with backing from the Social Interventions Research and Evaluation Network (SIREN) at UCSF and a broad coalition of health systems, EHR vendors, and community organizations.

The accelerator model matters because it's not one company deciding how SDOH should work. It's a consensus process — clinicians, informaticists, and implementers debating terminology bindings, profile constraints, and workflow patterns until they reach agreement.

Step 3: Standardize the terminology

For each SDOH domain, Gravity mapped existing screening tools and interventions to standard code systems: LOINC for screening instruments (PRAPARE, AHC-HRSN), SNOMED CT and ICD-10-CM for conditions, and SNOMED CT for interventions and goals. This is the unglamorous foundation work — deciding that "patient reports not having enough food" maps to a specific LOINC code, so that every system records it the same way.

Step 4: Publish a FHIR Implementation Guide

Gravity published the SDOH Clinical Care FHIR IG (STU 2.2), defining profiles for Conditions, Goals, ServiceRequests, Procedures, and Observations specific to SDOH workflows. These profiles layer on top of US Core — they don't reinvent the wheel, they constrain existing US Core profiles with SDOH-specific value sets and must-support elements.

Step 5: Get adopted into USCDI

Here's where it becomes mandatory. ONC incorporated Gravity's SDOH data elements into USCDI v2 (2022). Once something is in USCDI, it's on the path to regulatory enforcement. ONC expanded the SDOH elements further in v3, v4, and v5.

Step 6: It becomes law

USCDI v3 — which includes SDOH data elements — became mandatory on January 1, 2026 under the HTI-1 final rule. What started as a consensus project in 2019 is now a federal requirement in 2026. That's the pipeline.

Industry need identified
    ↓
HL7 FHIR Accelerator formed (consensus process)
    ↓
Terminology standardized (LOINC, SNOMED, ICD-10)
    ↓
FHIR Implementation Guide published
    ↓
ONC adopts data elements into USCDI
    ↓
US Core incorporates into FHIR profiles
    ↓
Federal rulemaking makes it mandatory

Every major new data domain in healthcare interoperability follows this path. Understanding it tells you not just what's required today, but what's coming next.

Other FHIR Accelerators Following the Same Path

Gravity isn't the only accelerator working through this pipeline. The one you should know about is Da Vinci — it targets payer-provider exchange (prior auth, coverage requirements, quality measures) and has a regulatory mandate landing January 2027. CMS-0057-F requires payers to implement FHIR APIs using Da Vinci IGs. Same path as Gravity: industry consensus → published IGs → CMS adopted them into regulation.

Others worth tracking: CARIN Alliance (consumer claims access, already mandated), CodeX/mCODE (oncology, growing adoption at cancer centers), Helios (public health reporting, in production), and Vulcan (clinical research, earlier stage). Each follows the same pipeline — the only question is how far along they are.

The Regulatory Timeline

Standards don't matter without enforcement. Three regulations turned FHIR from aspirational to mandatory:

ONC Cures Act Final Rule (May 2020) — ONC mandated FHIR R4 APIs and USCDI v1 for certified health IT, following Congress's direction in the 21st Century Cures Act (2016). This is where FHIR went from "nice to have" to "legally required." The g(10) certification criterion specifically requires FHIR R4 with SMART on FHIR (OAuth2-based) authorization — every certified EHR must support it.

HTI-1 Final Rule (December 2023) — Updated the certification program to require USCDI v3 as of January 1, 2026. This is the current regulatory baseline. (The HTI-2 proposed rule would have pushed to USCDI v4 and added FHIR Subscription requirements, but it was largely withdrawn in December 2025. Worth watching — it could get revived.)

CMS-0057-F (January 2027) — Extends the FHIR mandate from EHR vendors to health insurers. Payers must implement Patient Access, Provider Access, and Prior Authorization APIs using FHIR and Da Vinci IGs. This is a big deal — it means the vendor side of every prior auth integration currently handled via fax and proprietary portals is about to become a FHIR endpoint.

The bottom line: if you're building health IT in the US, FHIR R4 + USCDI v3 + US Core 6.1.0 is the compliance baseline. Legally mandated.

The Cheat Sheet

tl;dr: FHIR is the envelope, USCDI is the letter, and US Core is the form template. Get them confused and you'll spend months building something that technically sends FHIR but doesn't meet compliance requirements. Get them right and the entire IG ecosystem — Gravity, Da Vinci, CARIN, CodeX — slots into the same architecture.

Ready to build? Build a SMART on FHIR app in 30 minutes using a sandbox with realistic synthetic data. Or just browse the API →

Related posts

• Your FHIR Architecture Determines Your Test Data Strategy — Facade, hybrid, or FHIR-native — each architecture breaks differently. Here's what to test for each model and what breaks when you don't.
• FHIR Is Not Enough: Real-Time Integrations Still Need HL7v2 — FHIR answers 'what does this patient look like now?' To ask for changes you'll have to remember how HL7v2 works.
• Read from FHIR? np. Write to FHIR? please. — A federal survey of 2,253 hospitals: read-side FHIR is table stakes. The real opportunity is write-side clinical integrations.

All posts · Home · Docs