Quick answer
Treat a bulk export as an asynchronous data delivery that requires reconciliation. Inspect its manifest, files and errors, validate expected resources and apply a documented incremental-load strategy. A successful HTTP response can accompany partial export success, so transport completion alone should not refresh a production dashboard.
Define the analytic population before requesting files
A SNF group wants a nightly dataset for occupancy and service analysis. The export endpoint produces files successfully, but the dashboard's totals drift because one resource type fails and deleted records remain in the warehouse.
The HL7 Bulk Data Access 3.0.0 export guide describes asynchronous requests, progress and output manifests. It permits partial success with error output and leaves legal sharing arrangements, real-time exchange and patient matching outside scope. Confirm the supplier's implemented version and options before designing the loader.
Write the population contract: facilities, resident cohort, resource types, time basis, exclusions, identifier handling and expected update frequency. A group identifier is meaningful only if someone maintains the group's membership correctly.
Reconcile each stage separately
Use an original load-control table:
| Stage | Evidence retained | Stop or review condition |
|---|---|---|
| Request accepted | Parameters, cohort and request identifier | Wrong facility or resource scope |
| Export completes | Final manifest and transaction time | Incomplete job or unresolved status |
| Files retrieved | Manifest entries matched to actual files | Missing, expired or unreadable file |
| Resources parsed | Type, identifier and validation results | Malformed or unexpected content |
| Errors reviewed | Error files and impact on requested scope | Partial success affects published measures |
| Warehouse applied | Insert/update/delete and rejection counts | Unexplained reconciliation difference |
| Dashboard released | Data cutoff and validation sign-off | Measures use mixed or stale populations |
If the implementation uses partial manifests, follow every next-manifest link and reconcile the combined file list before declaring the delivery complete. The first manifest can be valid without describing the whole export.
Do not place access tokens or sensitive file URLs in an unrestricted operations report. Evidence must be retained in an appropriately protected location.
Work a partial-success example
Suppose a synthetic export should represent 100 residents and their relevant observations. The manifest supplies 100 Patient resources, 900 Observation resources and an error file indicating failures for part of the requested observation population. Patient completeness does not establish observation completeness. The dashboard should not quietly publish a rate whose denominator includes residents whose relevant observations are missing.
Record the affected resource types and, where possible, affected records. Decide whether to retry, quarantine the load or publish a clearly bounded dataset under an approved analytic policy. A row-count threshold alone cannot distinguish a legitimate low-volume day from missing data.
Design incremental updates deliberately
Establish how the supplier supports time-based incremental requests, resource updates, deletions and cohort changes. The guide includes optional deleted-resource output; do not assume every deployment supplies it. Agree on what the client must do when a resident leaves a group or a resource is removed.
A fictional warehouse contains 1,000 records. The next load supplies 40 new records, 20 changed versions of existing records and five deletions. The expected final unique-record count is 1,035 if those categories are distinct and the supplied scope is complete. Adding all 60 rows without replacing versions or handling deletions yields a different, incorrect population. Preserve resource identity and version logic through the load.
Test retries. Reprocessing the same successful delivery should not duplicate resources or reapply changes incorrectly. Coordinate the next incremental boundary with the documented export semantics so late updates are not skipped. The appropriate strategy depends on the implemented version and supplier behavior; a universal timestamp recipe is insufficient.
Prove operational recovery
Rehearse an expired download URL, a corrupted file, a changed schema and a job that completes after the reporting cutoff. Ensure the previous validated dataset remains distinguishable from the incomplete new one. Staff need to see data freshness and known gaps rather than a dashboard that looks current because its page loaded today.
Acceptance should include a full load, incremental update, deletion or documented alternative, partial failure and replay test. The result is a repeatable analytics feed with an explainable population, not merely a downloadable collection of FHIR files.
Questions & answers
Does HTTP 200 mean all requested resources were exported?
No. The Bulk Data guide allows partial success with errors described in the completion response. The loader must inspect the manifest and error output.
Does Bulk Data solve resident matching and legal data sharing?
No. The guide explicitly leaves patient matching and the legal sharing framework outside its scope. Those need separate designs.
Primary sources
Use the cited source and its applicable version when making a facility-specific decision. These guides explain operational evaluation methods; they are not individualized clinical, coding, or legal advice.