Bulk Data Access IG
2.0.0 - ci-build International flag

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

CapabilityStatement: Capability Statement

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

FHIR Bulk Data Access Implementation Guide

  • Implementation Guide Version: 2.0.0
  • FHIR Version: 4.0.1
  • Supported Formats: json
  • Supported Patch Formats:
  • Published on: 2021-07-29
  • Published by: HL7 International / FHIR Infrastructure

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

SHALL Support the Following Implementation Guides

FHIR RESTful Capabilities

Mode: 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.

Security

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.

Summary of System-wide Interactions

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCSearches_include_revincludeOperations
Group $export
Patient $export

Resource Conformance: supported Group

Core FHIR Resource
Group
Reference Policy
Interaction summary

    Extended Operations
    ConformanceOperationDocumentation
    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 Group resource. This enables clients to discover available groups based on stable characteristics such as Group.identifier.

    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.

    Resource Conformance: supported Patient

    Core FHIR Resource
    Patient
    Reference Policy
    Interaction summary

      Extended Operations
      ConformanceOperationDocumentation
      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.