BulkDataAccess IG: STU1

This page is part of the FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 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

CapabilityStatement: bulk-data

Formats: Narrative, XML, JSON

Raw xml


<CapabilityStatement xmlns="http://hl7.org/fhir">
  <id value="bulk-data"/>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml"><h2>BulkDataIGCapabilityStatement</h2><div><p>This Section describes the expected capabilities of a FHIR Bulk Data Server actor which is responsible for providing responses to the queries submitted by the FHIR Bulk Data Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by FHIR Bulk Data Servers are defined. Systems implementing this capability statement should meet the requirements set by the <a href="https://fhir.org/ig/HL7/bulk-data/">Bulk Data Implementation Guide</a>. FHIR Bulk Data Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.</p>
</div><table><tr><td>Mode</td><td>SERVER</td></tr><tr><td>Description</td><td>The Bulk Data (Flat FHIR) Server **SHOULD**:

1. Export data from a FHIR server whether or not it is associated with a patient. This supports use cases like backing up a server or exporting terminology data by restricting the resources returned using the _type parameter.
1. Obtain data on all patients listed in a single FHIR Group Resource. 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. Note: How these groups are defined is implementation specific for each FHIR system. For example, a payer may send a healthcare institution a roster file that can be imported into their EHR to create or update a FHIR group. Group membership could be based upon explicit attributes of the patient, such as: age, sex or a particular condition such as PTSD or Chronic Opioid use, or on more complex attributes, such as a recent inpatient discharge or membership in the population used to calculate a quality measure. FHIR-based group management is out of scope for the current version of this implementation guide.
1. Export data from a FHIR server for all data associated with patients. This supports use cases like transmitting all data about patients or clinical care between systems.</td></tr><tr><td>Transaction</td><td></td></tr><tr><td>System History</td><td></td></tr><tr><td>System Search</td><td></td></tr></table><table><tr><th><b>Resource Type</b></th><th><b>Profile</b></th><th><b title="GET a resource (read interaction)">Read</b></th><th><b title="GET all set of resources of the type (search interaction)">Search</b></th><th><b title="PUT a new resource version (update interaction)">Update</b></th><th><b title="POST a new resource (create interaction)">Create</b></th></tr></table></div>
  </text>
  <url value="http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data"/>
  <version value="1.0.0"/>
  <name value="BulkDataIGCapabilityStatement"/>
  <title
         value="FHIR Bulk Data Export (Flat FHIR) Implementation Guide CapabilityStatement"/>
  <status value="active"/>
  <experimental value="false"/>
  <date value="2019-06-04T10:00:00+10:00"/>
  <publisher value="SMART Health IT"/>
  <contact>
    <name value="Ricky Sahu"/>
    <telecom>
      <system value="email"/>
      <value value="ricky@1up.health"/>
    </telecom>
  </contact>
  <contact>
    <name value="Dan Gottlieb"/>
    <telecom>
      <system value="email"/>
      <value value="daniel.gottlieb@childrens.harvard.edu"/>
    </telecom>
  </contact>
  <contact>
    <name value="Josh Mandel"/>
    <telecom>
      <system value="email"/>
      <value value="joshua.mandel@childrens.harvard.edu"/>
    </telecom>
  </contact>
  <contact>
    <name value="Vlad Ignatov"/>
    <telecom>
      <system value="email"/>
      <value value="Vladimir.Ignatov@childrens.harvard.edu"/>
    </telecom>
  </contact>
  <description
               value="This Section describes the expected capabilities of a FHIR Bulk Data Server actor which is responsible for providing responses to the queries submitted by the FHIR Bulk Data Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by FHIR Bulk Data Servers are defined. Systems implementing this capability statement should meet the requirements set by the [Bulk Data Implementation Guide](https://fhir.org/ig/HL7/bulk-data/). FHIR Bulk Data Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements."/>
  <jurisdiction>
    <coding>
      <system value="http://unstats.un.org/unsd/methods/m49/m49.htm"/>
      <code value="001"/>
      <display value="World"/>
    </coding>
  </jurisdiction>
  <kind value="requirements"/>
  <fhirVersion value="4.0.0"/>
  <format value="json"/>
  <patchFormat value="application/json-patch+json"/>
  <implementationGuide
                       value="http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/ig"/>
  <rest>
    <mode value="server"/>
    <documentation
                   value="The Bulk Data (Flat FHIR) Server **SHOULD**:

1. Export data from a FHIR server whether or not it is associated with a patient. This supports use cases like backing up a server or exporting terminology data by restricting the resources returned using the _type parameter.
1. Obtain data on all patients listed in a single FHIR Group Resource. 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. Note: How these groups are defined is implementation specific for each FHIR system. For example, a payer may send a healthcare institution a roster file that can be imported into their EHR to create or update a FHIR group. Group membership could be based upon explicit attributes of the patient, such as: age, sex or a particular condition such as PTSD or Chronic Opioid use, or on more complex attributes, such as a recent inpatient discharge or membership in the population used to calculate a quality measure. FHIR-based group management is out of scope for the current version of this implementation guide.
1. Export data from a FHIR server for all data associated with patients. This supports use cases like transmitting all data about patients or clinical care between systems."/>
    <security>
      <description
                   value="1. See the [Authorization Guide](authorization/index.html) section for requirements and recommendations.
1. This specification describes requirements for requesting an access token
        through the use of an OAuth 2.0 client credentials flow, with a [JWT
        assertion](https://tools.ietf.org/html/rfc7523) as the
        client&#39;s authentication mechanism."/>
    </security>
    <operation>
      <extension
                 url="http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation">
        <valueCode value="SHOULD"/>
      </extension>
      <name value="export"/>
      <definition value="OperationDefinition/BulkDataExport"/>
    </operation>
    <operation>
      <extension
                 url="http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation">
        <valueCode value="SHOULD"/>
      </extension>
      <name value="patient-export"/>
      <definition value="OperationDefinition/PatientLevelExport"/>
    </operation>
    <operation>
      <extension
                 url="http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation">
        <valueCode value="SHOULD"/>
      </extension>
      <name value="group-export"/>
      <definition value="OperationDefinition/GroupLevelExport"/>
    </operation>
  </rest>
</CapabilityStatement>