Helix AU Core
0.1.0 - ci-build

Helix AU Core - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Architecture

Architecture

Overview

NOTE: This section is a work in progress.

Rate Limiting

The Helix FHIR API employs rate limiting to ensure fair use of the API and to adhere to security principles. Rate limiting is per IP address. Telstra Health reserves the right to change rate limiting without notice but will endeavour to discuss any impact with partners.

If you have specific rate requirements please discuss with the partner support team.

Partners should be prepared to handle transient HTTP errors resulting from rate limiting. This includes but is not limited to 429 and 503 response codes.

Transient HTTP Errors & Error Handling

Partners should be prepared to handle transient HTTP errors and retry the operation as required. Errors might be returned from any layer of the system not just the FHIR server so partners should design their integration to handle the full range of HTTP and network error conditions.

Partners are expected to handle scenarios such as the following:

  • Retry transient errors to ensure reliable delivery.
  • Maintain robust monitoring that alerts when permanent failures occur.
  • Ensure that permanent failures do not result in cascading failures and infinite retries.

Polling vs Change Notifications

Partners are expected to use change notification mechanisms such as Subscriptions to avoid polling operations.

Subscriptions can be used in different ways depending on the use case:

  1. Using the header field to receive the full resource payload in the REST hook.
  2. Omitting the header field to receive only the notification that the resource has changed.

Option 1 has a higher overhead on both the source and destination system, so it's impact should be considered before implementing that pattern.

Option 2 can be used to only fetch resources when a change has occurred within Helix. For resources that change frequently the integration should buffer the notifications and limit fetching to a particular schedule. E.g. every five minutes if a change has occured.