FHIR Bulk Data 3.0 turns export into an asynchronous job

The API operation creates a job

The guide says the Bulk Data Export Operation initiates asynchronous generation of data for a defined population or server-level request. A successful kickoff does not return the finished dataset. It can return HTTP 202 Accepted and a Content-Location URL that the client uses to check progress. The client, job, parameters, and polling location therefore become part of the exchange record.

This matters for platform claims. A product can call an export endpoint but still mishandle duplicate kickoffs, job identity, cancellation, retry timing, expiration, or recovery after a client or server restart. Buyers should test the state machine and retained evidence rather than treat one successful sample download as proof of a reliable bulk exchange.

Polling is a governed interaction

The implementation guide describes status polling and recommends exponential backoff, while allowing a server to provide Retry-After information and respond when a client polls too frequently. Those details make scheduling and failure handling observable. A client that ignores server guidance can create avoidable load; a server that loses job state can leave the requester unable to distinguish delay from failure.

A production record should preserve kickoff time, request parameters, authorization context, polling location, response codes, retry instructions, progress information when supplied, terminal status, and cancellation. Operational monitoring should distinguish a slow valid job, rate limiting, expired status URL, authorization failure, server error, and an export that completed with some files unavailable.

The manifest is not a completeness certificate

At completion, the server returns a JSON manifest with metadata and links to generated files. The guide also defines error-file handling and allows an overall operation to succeed even when some requested resources could not be exported. That means a 200 response or available file set cannot be treated as proof that every expected resource, patient, or interval is present.

Buyers need reconciliation outside the transport. Compare requested scope with manifest entries, resource types, counts or other available control totals, time filters, deleted-data handling, error files, and downstream load results. Preserve the original manifest and file metadata so later retries or URL refreshes do not erase what the client first received.

Authorization follows the data to the files

The guide recommends OAuth 2.0 access management through the SMART Backend Services Authorization Profile and states that status and output-file requests requiring access tokens are protected consistently with the kickoff. It also requires servers to limit returned resources to those for which the client is authorized. Local policy and out-of-band restrictions can further shape the returned population.

A useful test uses an authorized cohort, a disallowed resource type, an expired token, a client attempting to retrieve another client's output, and a file URL after its availability window. The source describes an implementation pattern; it does not prove privacy compliance, appropriate consent, complete policy enforcement, clinical fitness, or conformance by any specific server or client.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.