FHIR Gateway Introduction
The FHIR Gateway Endpoint module creates a FHIR server that acts as a proxy for one or more target FHIR servers.
The FHIR Gateway provides the benefits of a Smile CDR FHIR endpoint over top of the target servers. This includes:
_elements
and _fhirpath
parametersWhen the FHIR Gateway is placed in front of multiple target servers, it can be used to present a collection of servers as a single unified FHIR endpoint. This can be particularly useful when implementing APIs for SMART on FHIR applications, since these applications will often expect a single endpoint through which all data flows.
The FHIR Gateway is also designed to avoid revealing details about the internal FHIR servers. Internal server addresses, paging URLs, etc. are all obscured by the FHIR Gateway in its responses to clients.
Additional logging can be enabled in order to troubleshoot Gateway routing issues. See FHIR Gateway Troubleshooting Log for details.
This section lists the known limitations on this module.
$meta
, $meta-add
, $meta-delete
, $graphql
, $process-message
and $everything
operations are supported by default. However, it is possible to add support for custom operations by configuring Custom Operation Providers.$everything
operation on instance and type level is supported only for Patient resource.DELETE Observation?status=outdated
) is NOT supported by FHIR Gateway module.PATCH
operation is NOT supported by FHIR Gateway.As mentioned in the Consent Service documentation, Consent Service can be enabled and implemented for FHIR Gateway modules using JavaScript or Java APIs. Note though that for JavaScript implementations, the following APIs are NOT available for FHIR Gateway modules: