The expected capabilities of a Data Provider actor (e.g., EHR systems, data warehouses, and other clinical and administrative systems that aim to interoperate by sharing large FHIR datasets) which is responsible for providing responses to requests submitted by a Data Consumer actor. Systems implementing this capability statement SHOULD meet the requirements set by the Bulk Data Access Implementation Guide. A Data Consumer MAY choose from this list to access necessary data based on use cases and other contextual requirements.

FHIR Operation to publish bulk data files for retrieval by Data Consumers. A Data Provider responds to GET requests at a path ending in /$bulk-publish by returning a Bulk Data Publish Manifest containing metadata and links to available Bulk Data files. Unlike $export, this operation does not initiate on-demand data generation; instead, it provides access to static or periodically updated datasets published by the Data Provider. The Bulk Publish API does not require a FHIR server implementation; many Data Providers may implement it using a simple HTTP server that returns a manifest in response to GET requests.

FHIR Operation through which an authenticated and authorized Data Provider submits Bulk FHIR Data to a Data Consumer and receives status information regarding the Data Consumer's receipt and processing of the data. The Data Provider provides one or more manifest URLs pointing to pre-coordinated FHIR data sets, along with metadata needed for the Data Consumer to retrieve and process the files.

This operation receives status updates about the submission after a Data Provider has kicked off a Bulk Submit operation. For example, the Data Consumer may indicate files it was unable to retrieve, resources that failed validation, or resources that could not be merged into an existing data set. The Data Consumer may also return processed data such as computed quality measures or de-identified versions of the submitted data. The Data Provider receives a 202 Accepted response with a Content-Location header and then polls that URL according to the FHIR Asynchronous Bulk Interaction Pattern.

Common kick-off request parameters for operations and defined interactions that implement the FHIR Asynchronous Bulk Interaction Pattern. This pattern supports asynchronous generation of large FHIR datasets and is triggered by the Prefer: respond-async header on the underlying request.

FHIR Operation through which an authenticated and authorized Data Consumer requests a detailed set of FHIR resources of diverse resource types pertaining to all members of the specified Group from a Data Provider. The Data Provider's FHIR Resource Server SHALL support invocation of this operation using the FHIR Asynchronous Bulk Interaction Pattern

FHIR Operation through which an authenticated and authorized Data Consumer requests a detailed set of FHIR resources of diverse resource types pertaining to all patients from a Data Provider. The Data Provider's FHIR Resource Server SHALL support invocation of this operation using the FHIR Asynchronous Bulk Interaction Pattern

FHIR Operation through which an authenticated and authorized Data Consumer may request bulk FHIR data from a Data Provider, whether or not the data is associated with a patient. This supports use cases like backing up a Data Provider's FHIR server, or exporting terminology data by restricting the resources returned using the _type parameter. The Data Provider's FHIR Resource Server SHALL support invocation of this operation using the FHIR Asynchronous Bulk Interaction Pattern

Logical model describing a standard format to provide links to FHIR Bulk Data files and related metadata.

Logical model describing the manifest returned by a $bulk-publish endpoint. Extends BulkDataManifest with fields to support incremental updates through epochs and to advertise a Data Provider's update cadence.

Logical model describing the status manifest returned by a Data Consumer in response to a $bulk-submit-status polling request. Extends BulkDataManifest with a submissionId linking the manifest to the originating submission, and a manifestUrl on output and error items linking them back to the Data Provider's submitted manifests.

This Group resource profile enables the creation of patient cohorts, practitioner cohorts, and sets of devices based on characteristics defined using FHIR RESTful search filters. It can be used to constrain the population included in a bulk export request.

Extension to define the population of the group using FHIR REST API parameters. For example, the following extension would limit the population of the group to patients with an ambulatory encounter in January 2024:

"modifierExtension" : [{
  "url" : "http://hl7.org/fhir/uv/bulkdata/StructureDefinition/member-filter",
  "valueExpression" : {
    "language" : "application/x-fhir-query",
    "expression" : "Encounter?class=http://terminology.hl7.org/CodeSystem/v3-ActCode|AMB&date=ge2024-01-01&date=le2024-01-31"
  }
}]

Extension used by a server to indicate to a client when the members in a dynamic group were last updated. For example, the following extension would indicate that the group members were last updated January 1st 2024:

"Extension" : [{
  "url" : "http://hl7.org/fhir/uv/bulkdata/StructureDefinition/members-refreshed",
  "valueDateTime" : "2024-01-01T13:28:17-05:00"
}]

Extension used in a CapabilityStatement to indicate that the parent resource type or search parameter is not supported for use in a bulk data export operation. For example, the following extension would indicate that the AllergyIntolerance.clinical-status search parameter can not be used in a _typeFilter parameter on this server.

  "searchParam": [{
    "name": "clinical-status",
    "type": "token",
    "extension": [{
      "url": "http://hl7.org/fhir/uv/bulkdata/Extension/operation-not-supported",
      "valueCanonical": "http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data"
    }]
  }]

Metadata inclusion options for Bulk Data Access Export Operation includeAssociatedData parameter

Status codes for the Bulk Data Submit operation submissionStatus parameter.

Value Set to constrain the type element in a Group to person, practitioner and device

Metadata inclusion options for Bulk Data Access Export Operation includeAssociatedData parameter

Blue cross plan member group with members filtered to patients that have an active diagnosis of diabetes on their problem list and an ambulatory encounter in January 2024

Example Bulk Data output manifest when organizeOutputBy is not populated.

Example Bulk Data output manifest when organizeOutputBy is Patient and allowPartialManifests is true.

Example Bulk Publish manifest after the first incremental update.

Example Bulk Publish manifest at the epoch start.

Example OperationOutcome describing resource-level validation failures for a bulk submit.

Example bulk submit status manifest returned by a Data Consumer.

Example OperationOutcome describing manifest-level submit status.

Example transaction bundle representing a deleted resource in a bulk data deleted output file.

Example OperationOutcome returned in the body of an error status response for a bulk data export.

Example Bulk Data output manifest when organizeOutputBy is Patient and allowPartialManifests is true.

Example minimal, non-incremental Bulk Publish manifest.