FHIR R4 APIs with Bulk Data Access

Group Export

Overview

The Group Export operation is used to obtain FHIR resources for all members of a specified group of patients.

An export process uses the FHIR Asynchronous Request Pattern to kick off the export job for a group of patients. Once the export job is kicked off, you can check the status of the job using the URL returned in the Content-Location header from the kick-off response. Once the job is complete, the status request returns a list of file URLs that may be requested to download the content of the file. After the appropriate ndjson files are downloaded, use the delete request to clean up the files that are no longer needed.

The Group Export operation exports resources required for United States Core Data for Interoperability V1 (USCDI). For a full list of resources, see the US Core Profiles. When the _type parameter is used, it returns only the FHIR resources specified. Use the _type parameter to filter the resources required for a specific use case. Limiting the number of requested resources in the _type parameter is recommended to decrease response times.

Recommendations

• Use the _type parameter whenever possible to improve response times and minimize storage requirements. You can use _typeFilter to further refine the returned results.
• Use the _since parameter to limit the export to only the relevant date range.
• Customers should follow an Exponential Backoff approach when polling for status as outlined in the FHIR Bulk Data Access IG.
• Retrieve files promptly because the exported content expires after 30 days.
• Once the files are retrieved, use the delete request to clean up the data from your request.
• Healthcare organizations may create groups containing up to 20,000 patients. However, the recommended group size for optimal performance is 10,000 patients or less.

Testing in Sandbox

To request bulk data endpoints in the sandbox environment, use one of the following group IDs to kick off a group export and then perform the subsequent requests:

• Group with 3 patients: 11ec-d16a-c763b73e-98e8-a31715e6a2bf
• Group with 10 patients: 11ec-d16a-b40370f8-9d31-577f11a339c5

Example

CopyGET https://fhir-ehr.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/Group/11ec-d16a-c763b73e-98e8-a31715e6a2bf/$export?_type=Patient

Patient Export

Overview

The Patient Export operation is used to obtain FHIR resources for the list of patients provided in the request as an alternative to creating a group.

An export process uses the FHIR Asynchronous Request Pattern to kick off the export job for the provided list of patients. Once the export job is kicked off, you can check the status of the job using the URL returned in the Content-Location header from the kick-off response. Once the job is complete, the status request returns a list of file URLs that may be requested to download the content of the file. After the appropriate ndjson files are downloaded, use the delete request to clean up the files that are no longer needed.

You can also export Location, Organization, Practitioner, Provenance, and RelatedPerson if at least one clinical resource is being exported as well.

When the _type parameter is used, only the FHIR resources specified are returned. Use the _type parameter to filter the resources required for a specific use case. Limiting the number of requested resources in the _type parameter is recommended to decrease response times.

Recommendations

• Use the _type parameter whenever possible to improve response times and minimize storage requirements. You can also use _typeFilter to further refine the returned results.
• Use the _since parameter to limit the export to only the relevant date range.
• Customers should follow an Exponential Backoff approach when polling for status as outlined in the FHIR Bulk Data Access IG.
• Retrieve files promptly because the exported content expires after 30 days.
• Once the files are retrieved, use the delete request to clean up the data from your request.
• The Patient Export operation supports a list of up to 20,000 patients. However, the recommended size for optimal performance is 10,000 patients or less.