FHIR Bulk Data Access

Unlike standard FHIR RESTful interactions, Bulk Data Access uses a kick-off and poll pattern. A client initiates an export request, and the server returns an immediate 202 Accepted status with a Content-Location polling URI. The server processes the request offline, generating flat NDJSON (Newline Delimited JSON) files. The client polls the status endpoint until the job is complete and receives signed download URLs. This decouples the request from the response, preventing timeouts on multi-million record exports.

Bulk Data Access forbids user-facing OAuth 2.0 flows (like the authorization code grant). It exclusively requires SMART Backend Services, a profile of the Client Credentials Grant (OAuth 2.0). This means a system, not a human user, authenticates. The client application presents a signed JSON Web Token (JWT) to the authorization server to obtain an access token. This machine-to-machine authorization model is essential for automated ETL pipelines and nightly ML training jobs that run without human intervention.

The authorization specification for server-to-server communication that enables FHIR Bulk Data Access. Unlike user-facing SMART on FHIR apps that use OAuth 2.0 with a user-in-the-loop, Backend Services allows a trusted client to obtain an access token without direct user interaction.

• Uses the client_credentials grant type with JWT assertion
• Requires pre-registration of the client's public key with the FHIR server
• Scopes control access to specific resource types and patient compartments
• Essential for automated ETL pipelines feeding machine learning workflows

The container resource that FHIR Bulk Data Access uses to package exported data. A Bulk Data response returns one or more NDJSON files, each containing a newline-delimited stream of FHIR resources, but the manifest itself is a Bundle resource of type batch-response.

• Each line in the NDJSON file is a complete FHIR resource (e.g., a Patient or Observation)
• The Bundle tracks the URLs of all generated files
• Supports pagination via link elements for large exports
• Enables resumable downloads if a connection drops mid-transfer

The minimum conformance standard for FHIR servers in the United States, defining which resources and elements must be supported for Bulk Data Access. Based on the U.S. Core Data for Interoperability (USCDI) standard, it ensures that exported datasets contain consistent, predictable fields across different EHR vendors.

• Mandates support for key clinical resources: Patient, Encounter, Observation, Condition, Procedure
• Defines must-support elements that servers must populate if data exists
• Required by the ONC Cures Act Final Rule for certified health IT
• Provides the semantic backbone for cross-institutional federated training datasets

An open community data standard maintained by OHDSI that is frequently the target destination for FHIR Bulk Data exports in research settings. While FHIR is an exchange standard, OMOP CDM is an analytics-optimized relational schema designed for large-scale observational studies.

• Transforms FHIR's nested resource model into flat, query-efficient tables
• Standardizes vocabularies across institutions using the OMOP Standardized Vocabularies
• Enables execution of the same analytical code across disparate sites
• Bulk Data + OMOP ETL is a common pattern for federated clinical analytics

A real-time notification mechanism that complements Bulk Data's batch-oriented approach. While Bulk Data Access is designed for large, periodic exports, FHIR Subscription enables a client to register interest in specific events and receive immediate notifications when data changes.

• Supports event-driven architectures for near-real-time model updates
• Uses the Subscription resource to define criteria and channel type
• Can trigger re-exports of incremental data changes
• Enables a hybrid pattern: periodic full exports via Bulk Data + incremental updates via Subscriptions

The FHIR resource that governs whether patient data can be included in a Bulk Data export. It records a patient's agreement, dissent, or policy-based authorization for data use, and servers must filter exported datasets based on active consent directives.

• Supports granular consent: by purpose, recipient, data category, and time period
• Integrates with FHIR Security Labels to tag sensitive data (e.g., mental health, substance abuse)
• Critical for federated learning compliance under GDPR's right to object
• Servers must exclude resources where consent is absent or explicitly denied