Overview
Flat FHIR — formally the FHIR Bulk Data Access IG, also called Bulk FHIR or Flat FHIR — is an Implementation Guide enabling efficient export of FHIR resources for an entire group or patient population as NDJSON (newline-delimited JSON) files rather than requiring individual resource API calls for each patient. It addresses a key limitation of standard FHIR APIs, which are optimized for patient-specific requests and scale poorly for population-level use cases.
Use cases span population-scale needs. Value-based care organizations need clinical data for their entire attributed population to support care management, analytics, and reporting. Quality reporting (HEDIS, MIPS, state reporting) requires data aggregated across large patient cohorts. Research projects require de-identified data across thousands to millions of patients. Public health surveillance during disease outbreaks requires rapid population data access. For each of these, requesting data patient-by-patient through standard FHIR APIs is impractical; Bulk Data Export provides the mechanism.
Technical protocol: The client initiates an export request specifying scope (Patient, Group, or System-level), the FHIR resource types to include, and optional filters. The server begins asynchronous export, processing the request and producing NDJSON files. The client polls a status endpoint; when export completes, the client receives a manifest with download URLs for the NDJSON files. Each file contains resources of a single type in NDJSON format (one JSON object per line). Clients download and process the files at their own pace.
Asynchronous architecture is central. Population-level export can take minutes to hours depending on data volume. Synchronous API patterns would time out; Bulk Data's asynchronous polling pattern supports long-running exports without connection limitations. Servers can process exports efficiently in background, and clients don't block waiting for response. Standard HTTP polling (202 Accepted status, Retry-After header) enables graceful asynchronous workflow.
Scope types: System-level export covers all data in the server (typically requires high privilege). Group-level export covers a defined group of patients (ACOs frequently use Group-level for attributed population). Patient-level export for a specific patient or set of patients. Scope selection depends on use case and authorization.
Authorization and security: Bulk Data requires OAuth 2.0 authorization with specific SMART on FHIR scopes (system/*.read or similar). Authorization is typically system-to-system rather than patient-authorized, given population-level access. Access is logged for audit. Filters can restrict resource types and time ranges.
Integration with CMS regulations: CMS's Interoperability and Patient Access Final Rule and subsequent rules have incorporated Bulk Data Export for provider and payer APIs. The Payer-to-Payer API (CMS-0057-F requires) uses Bulk Data for large-scale data exchange. The Provider Directory API may use Bulk Data. CMS's ACO and other value-based programs increasingly require or recommend Bulk Data capabilities for participant access to attributed-population data.
Vendor support: Major EHRs (Epic, Oracle Cerner, athenahealth) support Bulk Data APIs to varying degrees. HIEs and health data platforms (Redox, Particle Health, Health Gorilla) increasingly support Bulk Data access. CMS's Blue Button 2.0 and related Medicare APIs use Bulk Data concepts. FHIR platforms (Firely, Microsoft Azure API for FHIR, Google Cloud Healthcare API) provide Bulk Data capability.
For RCM operations, Bulk Data access supports: ACO attributed-population analytics, value-based care risk stratification, clinical quality reporting, claims-data reconciliation with clinical data, denial analytics at population scale, and care management programs. Practices participating in risk-bearing arrangements with FHIR-capable payers can benefit from Bulk Data access to attributed-population data without patient-by-patient API calls. Implementation requires: technical capability to consume NDJSON data, storage and processing infrastructure for large datasets, authorization setup (OAuth clients, certificates), and analytics tools supporting FHIR data formats.
Industry benchmark
Bulk Data IG: published, increasingly adopted. Use cases: population health, VBC analytics, quality reporting, research. Format: NDJSON files. CMS regulations: incorporated for provider and payer APIs.
Worked example
An ACO uses FHIR Bulk Data Export to retrieve clinical data for 18,000 attributed Medicare beneficiaries. The ACO initiates a Group-level export request specifying Patient, Encounter, Condition, Observation, MedicationRequest, and Procedure resources for the prior 12 months. The EHR server processes the request asynchronously over 45 minutes and produces 38 NDJSON files totaling 2.1GB. The ACO's analytics platform downloads and processes the files, integrating with claims data for comprehensive population health analytics and care gap identification.
Frequently asked questions — Flat FHIR (Bulk Data Export)
What's the difference from standard FHIR API?
Standard FHIR APIs optimize for patient-specific or small-scale queries. Bulk Data optimizes for population-scale export through asynchronous NDJSON file generation. Same FHIR data model; different access patterns.
When is Bulk Data appropriate?
Population-scale use cases: VBC analytics, quality reporting, research, public health surveillance. Not appropriate for patient-specific real-time access; use standard FHIR API for those.
What authorization does Bulk Data require?
OAuth 2.0 with system-level SMART on FHIR scopes (system/*.read or similar). Typically system-to-system authorization rather than patient-authorized. Access logged for audit.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.