The FHIR Gateway Endpoint module creates a FHIR server that acts as a proxy for another FHIR server.
The high level architecture is shown in the following diagram.
Although the third-party FHIR server can be another Smile CDR instance, it does not need to be. This proxy can serve several purposes in a solution architecture.
The FHIR Gateway Endpoint forwards incoming requests to a third-party FHIR server known as the Target Server.
During the module startup, the FHIR Gateway Endpoint module queries the target server to analyze its conformance statement (using the FHIR
This operation is crucial to the operation of the gateway: If the target server does not correctly generate a Capability Statement, the FHIR Gateway Endpoint module will fail to start. If the target server goes not describe a particular resource type or operation, that resource type or operation will not be available through the gateway.
Once the gateway is started, client requests are accepted and processed. Where necessary, they are forwarded to the target server for processing.
The following diagram shows the startup and operation of the module.
When creating a FHIR Gateway Endpoint module, the following configuration items are required:
The FHIR Gateway Target configures the client connection from the gateway to the target server. Most importantly, a FHIR version and Base URL should be set. Optionally, credentials and other details may also be set.
The Database section provides a database that is used for temporary local storage for the gateway. This can use the same schema that is used by the Cluster Manager database in a simple deployment, but it is generally preferable to create a dedicated schema for this purpose.
The HTTP Listener section provides the details for the listening server on the gateway itself. This defines the port and other details for the server in Smile CDR that clients will connect to.
FHIR Operations can be invoked on the target server, including custom operations (operations that are not defined in the core FHIR specification).
Note that special care should be taken when designing a security architecture if operations are enabled. Smile CDR permissions should be used to authotize users to invoke operations, but simple permissions may not always be sufficient: If an operation involved modifying or accessing sensitive/secure information, it may not be possible for Smile CDR to know this simply by examining the URL and method details.
For example, consider the
$render operation on the QuestionnaireResponse. This operation returns a rendered view of a QuestionnaireResponse. If a given user only has access to read resources from a specific Patient compartment, then this user should not be able to see all rendered QuestionnaireResponse instances. However, when this operation is invoked, it is not possible for Smile CDR to determine the subject of the QuestionnaireResponse simply by examining the OperationOutcome response. This should be considered when setting up such an infrastructure.
The Gateway will typically favor the FHIR encoding used by the target server when it returns its CapabilityStatement. For example, if the server returns a JSON CapabilityStatement, the Gateway will prefer the use of JSON even when the client calling the Gateway is using XML encoding. In this case, the JSON response from the target server will be converted to XML before being returned to the calling client.
If the client requests a non-FHIR response (via an
Accept header in the request), the Accept value will be passed verbatim to the target server.
The following configuration defines a simple gateway that uses an in-memory embedded H2 database and proxies requests from port 8000 to a target server on port 8200.
module.fhir_gateway.type =ENDPOINT_FHIR_GATEWAY module.fhir_gateway.requires.CLUSTERMGR =clustermgr module.fhir_gateway.requires.SECURITY_IN_UP =local_security module.fhir_gateway.config.port =8000 module.fhir_gateway.config.security.http.basic.enabled =true module.fhir_gateway.config.target_server.fhir_version =DSTU3 module.fhir_gateway.config.target_server.base_url =http://localhost:8200 module.fhir_gateway.config.db.url =jdbc:h2:file:./database/h2_gateway_database module.fhir_gateway.config.db.driver =H2_EMBEDDED module.fhir_gateway.config.db.username =SA module.fhir_gateway.config.db.password =SA
The HAPI FHIR CLI could be used to serve a target server for testing using the following command:
./hapi-fhir-cli run-server -v dstu3 -p 8200