Two health IT systems can both be “certified,” both speak FHIR, and still fail to exchange anything useful — because certification never said which specific pieces of clinical information had to travel, only that some form of standardized access had to exist. That gap is what the United States Core Data for Interoperability was built to close. And once the what is settled, a second question follows immediately: how does a health plan or public health agency pull that data for a hundred thousand patients at once, instead of one API call at a time? That’s the problem FHIR Bulk Data Access solves. Together, the two standards answer the two questions that matter most in interoperability — what data, and how much of it, at what scale.

What USCDI actually is

The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and constituent data elements maintained by the Office of the National Coordinator for Health IT (ONC), now operating as the Assistant Secretary for Technology Policy (ASTP). It answers a narrow but consequential question: when a certified health IT system says it can exchange patient data, which specific data does that promise cover?

Before USCDI, “interoperability” was defined loosely enough that vendors could satisfy certification requirements while still leaving huge categories of clinical information — care team members, clinical notes, provenance — outside the scope of what their systems reliably exchanged. USCDI replaced that ambiguity with an explicit, versioned list. Each data class (for example, Laboratory or Medications) is a functional grouping, and each class contains one or more data elements — the actual discrete fields, like a lab test’s result value or a medication’s start date — that certified systems must be able to exchange.

USCDI itself is not software, and it isn’t a messaging format. It’s a policy-and-content standard: a checklist of required data, published by ONC/ASTP and incorporated by reference into the ONC Health IT Certification Program’s regulations. The technical work of actually representing and transmitting that data falls to FHIR and the US Core Implementation Guide, described below.

Why USCDI has versions

USCDI is deliberately incremental. Rather than trying to define a complete, permanent data set up front, ONC publishes new versions on a roughly annual cadence, each one adding data classes or elements based on public comment, the Health IT Advisory Committee (HITAC) process, and gaps identified in the field. This matters because a version number is really a policy commitment: it determines what a certified health IT system is legally required to support, and by when.

As of 2024, the versions in play are:

  • USCDI v1 — the original baseline, adopted in the ONC Health IT Certification Program’s 2015 Edition regulations and long used as the default reference for the § 170.315(g)(10) “standardized API” certification criterion.
  • USCDI v2 — an intermediate expansion; not separately mandated as a certification baseline, but available for voluntary use.
  • USCDI v3 (published by ONC in July 2022) — added new data classes and elements, including facility information, encounter diagnosis, and expanded demographics such as sexual orientation and gender identity data. Under ONC’s HTI-1 final rule (published January 2024), USCDI v3 becomes the required certification baseline, replacing v1, with a compliance date of January 1, 2026. Both v1 and v3 are treated as acceptable in the interim.
  • USCDI v4 (published July 2023) — the newest version as of this writing, layering in additional elements touching medications, laboratory observations, and other refinements. USCDI v4 is available for voluntary adoption (for example, through ONC’s Standards Version Advancement Process) but is not yet a certification requirement.

The practical takeaway: “USCDI compliant” is not a single fixed target. It’s always version-specific, and the version that governs a given certified product depends on which certification criteria and compliance dates apply to it. Anyone evaluating a vendor’s interoperability claims in 2024 should ask which USCDI version — not just whether USCDI is supported at all.

Because ONC continues to revise both the data set and the certification timelines, exact version numbers, data classes, and compliance dates should always be checked against the current ONC/ASTP Interoperability Standards Advisory (ISA) and Interoperability Standards Platform pages rather than treated as permanently fixed.

How USCDI connects to certification

USCDI doesn’t stand alone — it’s woven into the regulatory certification criteria that EHR and health IT vendors must meet under the ONC Health IT Certification Program. The most relevant single criterion is § 170.315(g)(10), the “Standardized API for patient and population services” requirement.

Under g10, a certified Health IT Module must be able to respond to API requests for a patient’s data covering the full USCDI data set, using the FHIR standard and the corresponding implementation guide. In effect, g10 is the technical delivery mechanism, and USCDI is the content contract it has to fulfill. A vendor can implement a technically flawless FHIR API, but it isn’t g10-certifiable unless that API actually surfaces every required USCDI data class and element for both:

  • Single-patient access — a patient or their authorized app requesting that one patient’s own record.
  • Multiple-patient (population) access — a payer, accountable care organization, or public health authority requesting data for a defined group of patients, which is where FHIR Bulk Data Access comes in.

The Cures Act Final Rule and, more recently, the HTI-1 final rule (effective 2024, with staged compliance dates running into 2026) are the regulatory vehicles that update which USCDI version applies to g10 and related criteria, and they also govern related information-blocking provisions that discourage vendors from artificially limiting access to this same data.

Where US Core FHIR profiles fit in

USCDI defines what data is required in plain-language terms — “Problems,” “Smoking Status,” “Care Team Members.” It does not specify how those concepts should be represented as FHIR resources, fields, and value sets. That translation work is done by the US Core Implementation Guide, maintained by HL7 as a FHIR profile package specifically built for the U.S. regulatory context.

US Core takes each USCDI data element and maps it to a specific FHIR resource profile — for instance, a patient’s problem list elements map to the US Core Condition Problems and Health Concerns profile, while smoking status maps to a constrained US Core Observation profile. HL7 publishes a formal crosswalk between USCDI data elements and US Core profiles/FHIRPath expressions, which is the authoritative reference for developers building to a specific USCDI version.

Two nuances are worth flagging for accuracy:

  • US Core’s scope is broader than USCDI. Because FHIR resources need additional structural and “must support” elements to be implementable at all, many US Core profile fields don’t map back to any USCDI requirement — they exist for technical completeness, not regulatory mandate.
  • Not every USCDI element has a clean one-to-one US Core profile. Some require combining multiple resources or extensions, which is one reason new USCDI versions are often paired with a corresponding new US Core release.

Certified g10 systems are required to support both the applicable USCDI version and the compatible US Core version together — they move as a matched pair, not independently.

FHIR Bulk Data Access: exporting at population scale

Standard FHIR REST APIs are built around fetching one resource, or a small bundle of resources, per request — ideal for an app pulling up a single patient’s chart. That model breaks down for population-level use cases: a health plan analyzing quality measures across tens of thousands of members, a public health department pulling immunization records network-wide, or a research consortium assembling a cohort. Making one API call per patient per resource type at that scale is impractical.

The FHIR Bulk Data Access Implementation Guide, developed by HL7 in collaboration with the SMART Health IT project (informally nicknamed “Flat FHIR” for the flat, line-delimited output format it produces), defines a standardized alternative built around three ideas:

  1. Group- and system-level export. Rather than requesting one patient, a client can request an export scoped to a defined Group of patients, to a Patient-level export (one patient but multiple related resources), or to a system-level export covering an entire population the server manages.
  2. Asynchronous request/response. Because generating a large export can take minutes or hours, the client kicks off the job with a $export operation, the server responds immediately with a polling status URL, and the client checks back until the export is complete — rather than holding a connection open.
  3. NDJSON output. Instead of returning one large FHIR Bundle, the server produces newline-delimited JSON (NDJSON) files, one resource type per file (all Observations in one file, all Conditions in another). This is the “flat” structure that gives Flat FHIR its name — simpler to stream, parse, and load into downstream systems than deeply nested Bundles.

Access to a bulk export endpoint is authorized using the SMART Backend Services profile — OAuth 2.0 client-credentials-style authentication designed for system-to-system access where no user is present to log in interactively, which is a meaningfully different trust model from the patient-facing SMART App Launch flow used for single-patient apps.

Bulk data in practice: use cases as of 2024

FHIR Bulk Data Access underpins several production efforts already running in 2024:

  • CMS Blue Button 2.0 and the Beneficiary Claims Data API (BCDA) use FHIR-based bulk export so Medicare Accountable Care Organizations can retrieve claims data for their attributed beneficiary populations rather than record-by-record.
  • Payer-to-payer and payer APIs required under CMS interoperability rules increasingly rely on bulk export patterns for large-scale data transfer between health plans.
  • Public health reporting — including case reporting and registry submissions — benefits from group-level export when an agency needs data across a defined patient cohort rather than a single encounter.
  • Quality measurement and value-based care programs use bulk export to pull the clinical data needed for measure calculation across a payer’s or ACO’s full population, rather than through manual chart abstraction.

The common thread: anywhere USCDI defines what must be shared for one patient, FHIR Bulk Data Access defines how to get that same content for many patients in one coordinated operation — using the same underlying US Core-profiled resources.

Frequently Asked Questions

Is USCDI the same thing as FHIR?

No. USCDI is a content standard — a list of required data classes and elements — while FHIR is a technical data-exchange standard. They work together: FHIR (via the US Core Implementation Guide) defines how USCDI’s required data elements are represented as structured, exchangeable resources, but neither one replaces the other.

Which USCDI version is required for certification in 2024?

As of 2024, USCDI v1 remains the certification baseline referenced in existing regulations, but ONC’s HTI-1 final rule establishes USCDI v3 as the new baseline with a compliance date of January 1, 2026. USCDI v4, published in July 2023, is the newest version available but is not yet a mandatory certification requirement. Always verify current dates against HealthIT.gov.

What does “Flat FHIR” mean?

“Flat FHIR” is an informal nickname for the FHIR Bulk Data Access Implementation Guide. It refers to the newline-delimited JSON (NDJSON) files the standard produces — one flat file per resource type — rather than the deeply nested FHIR Bundle structure used in typical single-record API responses.

Does FHIR Bulk Data Access require patient-by-patient authorization?

No. Bulk export uses the SMART Backend Services authorization profile, a system-to-system OAuth 2.0 flow intended for pre-authorized organizational clients such as payers or public health agencies, rather than the patient-facing login flow used when an individual authorizes a personal health app.

How does US Core relate to USCDI in practice?

US Core is the FHIR implementation guide that translates USCDI’s plain-language data requirements into specific, testable FHIR resource profiles. A certified system’s API must implement the US Core profile version that corresponds to the USCDI version it claims to support; the two are published and updated as a coordinated pair, not independently.

This article is provided for general informational purposes about health IT interoperability standards and does not constitute legal, compliance, or medical advice. Consult official ONC/ASTP and HL7 publications and qualified counsel for certification or implementation decisions.

Sources: HealthIT.gov Interoperability Standards Platform — USCDI, HL7 FHIR Bulk Data Access Implementation Guide, HL7 US Core Implementation Guide, HealthIT.gov — Standardized API for Patient and Population Services, § 170.315(g)(10)