Represents a single item’s raw data as digital content. A binary resource can contain any type of content, such as text, image, pdf, or zip archive. Typically, Binary resources are used for managing content, such as:

• CDA Documents
• PDF Documents
• Images

Note: Retrieval of a Binary resource follows the FHIR asynchronous request pattern.

See also:
FHIR R4 Asynchronous Request Pattern
FHIR R4 Binary Resource.

Recommended Limits and Retry Strategies for Binary Requests

Because of the FHIR Services architecture, Binary requests are served from site servers rather than through the cloud-based FHIR platform. These services are not inherently scalable because a single service handles Binary requests for both Intergy and Prime Suite sites on each server. To prevent service degradation, implement rate limiting for Binary requests and follow the recommendations below.

Greenway Health recommends the following:

• Limit active concurrent Binary requests to 2–3 requests at a time. Because processing is asynchronous, consider a request complete only when the Binary upload fails, returns an error, or is successfully retrieved. If using multithreading, limit processing to 2–3 threads and allow each thread to handle only one complete request at a time.

• Limit retry attempts for a request: Greenway Health recommends a maximum of 3–5 retry attempts.

• Implement exponential backoff when errors occur by retrying requests after progressively longer intervals (for example, 1, 2, 4, and 8 seconds) to give the server time to recover if it becomes overloaded.

• If no Binary requests succeed within a 1-minute window, stop sending additional Binary requests and work with the shared client to reset the server connection, with assistance from Greenway Client Support as needed.

• Distinguish Binary service failures from FHIR platform failures by recognizing that failures limited to Binary requests may indicate an issue with the site server, whereas failures affecting all FHIR requests may indicate a FHIR server outage.