Bulk Data Access IG, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/bulk-data/ and changes regularly. See the Directory of published versions
Official URL: http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data | Version: 2.0.0 | |||
Active as of 2021-07-29 | Computable Name: BulkDataIGCapabilityStatement |
The expected capabilities of a Bulk 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 the queries submitted by a FHIR Bulk Data Client actor. Systems implementing this capability statement should meet the requirements set by the Bulk Data Access Implementation Guide. A FHIR Bulk Data Client has the option of choosing from this list to access necessary data based on use cases and other contextual requirements.
Raw OpenAPI-Swagger Definition file | Download
Generated Narrative: CapabilityStatement bulk-data
json
Note to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
This CapabilityStatement instantiates the CapabilityStatement FHIR Bulk Data Access Implementation Guide
server
These FHIR Operations initiate the generation of data to which the client is authorized -- whether that be all patients, a subset (defined group) of patients, or all available data contained in a FHIR server.
The FHIR server SHALL limit the data returned to only those FHIR resources for which the client is authorized.
The FHIR server SHALL support invocation of this operation using the FHIR Asynchronous Request Pattern. Servers SHALL support GET requests and MAY support POST requests that supply parameters using the FHIR Parameters Resource.
Servers SHOULD implement OAuth 2.0 access management in accordance with the SMART Backend Services: Authorization Guide. Implementations MAY include non-RESTful services that use authorization schemes other than OAuth 2.0, such as mutual-TLS or signed URLs.
The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include
_revinclude
Conformance | Operation | Documentation |
---|---|---|
SHOULD | $export | FHIR Operation to obtain a detailed set of FHIR resources of diverse resource types pertaining to all patients in specified Group. If a FHIR server supports Group-level data export, it SHOULD support reading and searching for The Patient Compartment SHOULD be used as a point of reference for recommended resources to be returned and, where applicable, Patient resources SHOULD be returned. Other resources outside of the patient compartment that are helpful in interpreting the patient data (such as Organization and Practitioner) MAY also be returned. |
Conformance | Operation | Documentation |
---|---|---|
SHOULD | $export | FHIR Operation to obtain a detailed set of FHIR resources of diverse resource types pertaining to all patients. The Patient Compartment SHOULD be used as a point of reference for recommended resources to be returned and, where applicable, Patient resources SHOULD be returned. Other resources outside of the patient compartment that are helpful in interpreting the patient data (such as Organization and Practitioner) MAY also be returned. |