The Bulk Data Access IG formalizes async $export for FHIR resources. Implementing it looks like adding one endpoint; production reality includes storage lifecycle, job status management, and manifest hosting that add up to real engineering work.
Async job lifecycle
1. Client POST Group/{id}/$export → server returns 202 Accepted with Content-Location: {status-url}. 2. Client polls status-url until server returns 200 OK with a JSON manifest listing NDJSON file URLs. 3. Client downloads NDJSON files (may be compressed). 4. Server may delete files after N hours or on client-signaled completion.
Each step is non-trivial. Server-side job tracking, poll rate-limiting, manifest formatting, and file storage all require deliberate design.
Storage sizing
A 12M-patient population exporting Patient + Observation + Encounter produces ~40-60GB of gzipped NDJSON. Multiply by retention (typically 24-72 hours) and by concurrent export jobs.
Output storage choices
- S3 or S3-compatible — dominant choice. Pre-signed URLs for client access, lifecycle rules for cleanup. - Local disk — works for small deployments, needs cleanup cron. - Cloud-provider blob — Azure Blob, GCS. Same as S3 pattern.
Manifest structure
The Bulk Data IG requires the manifest to list output (successful exports), deleted (resources deleted during export), and error (partial failures). Manifests missing deleted and error arrays fail conformance testing.
Common implementation gaps
| Gap | Impact |
|---|---|
No _since support |
Full exports every time, wastes resources |
| No delete tracking | Downstream MPI corruption |
| Sync manifest generation | Timeouts on large exports |
| Single-chunk NDJSON | Downstream ingestion pipelines choke |
No _typeFilter support |
Cannot filter QuestionnaireResponse by status |
Vendor state (mid-2026)
| Server | _since |
Delete tracking | _typeFilter |
Cloud storage |
|---|---|---|---|---|
| Aidbox 2409 | Yes | Yes | Yes | S3, GCS, Azure |
| HAPI JPA 7.x | Yes | Yes | Partial | S3, local |
| Medplum 3.x | Yes | Yes | Partial | S3 |
| Microsoft FHIR Server | Yes | Partial | Yes | Azure Blob |
Bulk Data is not a bolted-on feature — it's a subsystem with real infrastructure requirements. Budget for it accordingly at the design stage.