Bulk Data Access IG
1.1.0 - STU 2 Ballot

This page is part of the FHIR Bulk Data Access (Flat FHIR) (v1.1.0: STU 2 (FHIR R4) Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.1. For a full list of available versions, see the Directory of published versions

Bulk Data IG Home Page

Improvements to the IG include documentation on transmitting binary content in attachments; improvements to incremental update handling (retrieving historical data for new members of a group, propagating resource deletions); performance oriented enhancements (limiting fields returned using the _elements parameter, POST based kickoff requests with Parameters resource, addition of a patient parameter for filtering); improvements on handling metadata and other optional resources such as Provenance with the includeAssociatedData parameter; better export job management (clearer errors, signaling download completion to servers); documentation clarifications (inclusion of resources outside of Patient Compartment, parameter optionality for servers). See the change log for details.

Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. For example, a health system may want to periodically retrieve updated clinical data from an EHR to a research database, a provider may want to send clinical data on a roster of patients to their ACO to calculate quality measures, or an EHR may want to access claims data to close gaps in care. In most cases, access to these bulk-data exports is pre-authorized between the data holder and the data requester. The data exchange involves extracting a specific subset of fields from the source system, mapping the fields into a structured file format like CSV, and persisting the files in a server from which the requester can then download them into the target system. This multi-step process increases the cost of integration projects and can act as a counter-incentive to data liquidity.

Existing FHIR APIs work well for accessing small amounts of data, but large exports can require hundreds of thousands of requests. This implementation guide defines a standardized, FHIR based approach for exporting bulk data from a FHIR server to a pre-authorized client.

Conformance

To declare conformance with this IG, a server should include the following URL in its CapabilityStatement.instantiates: http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data

Use Cases

This implementation guide is designed to support sharing any data that can be represented in FHIR. This means that the IG should be useful for such diverse systems as:

  • “Native” FHIR servers that store FHIR resources directly
  • EHR systems and population health tools implementing FHIR as an interoperability layer
  • Financial systems implementing FHIR as an interoperability layer

US Core Data for Interoperability

Applies to: EHR systems that support the US Core Data for Interoperability.

This use case exports all resources needed for the US Core Data for Interoperability, as profiled by Argonaut. For a full list of these resources and profiles, see http://www.hl7.org/fhir/us/core/.

Common Financial Data Set

Applies to: Financial systems that support FHIR-based interoperability.

This use case exports all resources needed to convey a patient’s healththcare financial history, including Patient, ExplanationOfBenefit, Coverage, and Claim. While FHIR profiles are still being developed and standardized, see https://bluebutton.cms.gov/developers/#core-resources for a full-fledged example.

Additional Use Cases

  • Terminology data, e.g., to export all CodeSystem and ValueSet resources from a terminology server
  • Provider data to export information about an system’s full Practitioner, Location, and Organization list
  • Public health surveillance systems that do not require real-time exchange of data

Resources

Additional Documentation