The FHIR Bulk Data Access IG (STU 2.0.0 in the version current for 2026) is what Inferno tests against for CMS-0057-F conformance. The IG looks short, but the practical conformance bar covers more than the spec text suggests. Production implementations need to handle several patterns correctly, not just one. Here are seven best practices for Bulk Data and attribution coverage implementations targeting CMS-0057-F.
1. Use the Correct Prefer Header Pattern
The Bulk Data IG requires the client to send Prefer: respond-async on the export request. The server responds with 202 Accepted only if the request had this header. Implementations that respond with 202 without the Prefer header are technically non-conformant, even if the rest of the flow works.
The same applies to the optional Prefer: handling=strict header for error handling preferences. Implementations should respect both when present.
2. Return Conformant 202 Status With Content-Location
The 202 Accepted response must include a Content-Location header pointing to the status URL. The status URL is what the client polls for completion. Some implementations return 202 without Content-Location, expecting the client to know the status URL by convention, which is not conformant.
The status URL should be stable for the duration of the export. Clients that lose the URL cannot recover the export status; they have to start a new export.
3. Handle the Status Endpoint Correctly Across States
The status endpoint has three states: in-progress (202 with optional X-Progress header), failed (4xx or 5xx with an OperationOutcome), and completed (200 with a manifest). Implementations need to handle all three states cleanly.
Common gaps include not implementing the X-Progress header (which is optional but useful), returning generic 5xx errors instead of OperationOutcome for failures, and inconsistent handling of the completed state across different export sizes.
4. Produce Conformant Manifest at Completion
The completion response is a JSON manifest with specific required fields: transactionTime (when the export was initiated), request (the original request URL), requiresAccessToken (true if downloading the NDJSON files needs auth), output (the list of files), and error (the list of error files if any).
Implementations sometimes skip the error array, return non-ISO-8601 timestamps for transactionTime, or use non-standard structures for the output entries. These are conformance bugs that Inferno catches.
5. Output NDJSON, Not Batched JSON
The output files must be NDJSON: one FHIR resource per line, no array brackets, no commas between resources. Implementations that produce arrays of resources (batched JSON) are non-conformant even if consumers can sometimes handle the output.
For deeper coverage of this format-level requirement, the NDJSON Streaming vs Batched JSON for FHIR Bulk Exports comparison covers why the spec specifies NDJSON.
6. Handle the DELETE Operation on the Status URL
The client can DELETE the status URL to cancel an in-progress export. Implementations must support this and clean up any partial output. Implementations that ignore DELETE leak storage and continue exports that the client no longer wants.
The Inferno tests check this pattern. Implementations that pass Inferno on the happy path sometimes fail on the cancellation case.
7. Support the _outputFormat Parameter (Where Relevant)
The export request can specify _outputFormat, with the value typically being NDJSON. Implementations should accept the parameter and return appropriate Content-Type headers on the output files. Skipping the parameter handling is conformant in narrow cases but breaks for clients that rely on it.
How to Test Conformance Beyond Inferno
Inferno is the conformance suite of record for CMS-0057-F, but it does not test everything. Production-grade testing should include realistic-volume exports (100,000+ members, not just the test profiles), realistic data variety (multiple resource types, edge cases in resource content), and operational scenarios (concurrent exports, cancellation mid-export, status URL access after long delays).
For the operational monitoring that catches issues conformance testing misses, the Top 5 tools for monitoring FHIR Bulk Data export health covers the observability side. For the async export patterns that the conformance rules wrap, the Top 5 Async export patterns for FHIR Bulk Data implementations covers the operational layer.