The FHIR Storage (Relational) module is responsible for resource storage and retrieval. It stores data in two places:
To create a new FHIR Storage (Relational) module, you should first ensure that your host server (or virtual machine, docker container, etc.) has access to a dedicated directory with a sufficiently large amount of storage to keep its data.
This directory can be a mounted filesystem or a directory on a local disk but it should be dedicated to the given node. In other words, if this directory is network mounted, it should not be shared across multiple nodes of the cluster.
You will also require a relational database with a user and schema created. See the Platform Requirements page for information on supported database platforms.
When creating a FHIR Storage (Relational) module, you must first choose which version of FHIR it will support. There are multiple types of FHIR Storage (Relational) modules, and each one supports a specific version of FHIR.
In a basic deployment, a single Node with a FHIR Storage (RDBMS) module can be created. This module will service all FHIR requests. This architecture can easily be scaled hirozontally by creating multiple processes for this node.
In more complex architectures, it is possible to create multiple modules (generally on separate nodes) that share the same RDBMS connection details (i.e. the same connection URL). This is typically done when there is a separation of duties needed. This type of architecture is possible in Smile CDR as long as the considerations here are noted.
The FHIR Storage (RDBMS) module has a number of scheduled tasks that can selectively be enabled or disabled.
In most deployments there is no benefit to disabling these tasks, as they do not add any meaningful load to the system unless they detect work that needs doing. The exception to this rule is in deployments where you have multiple FHIR Storage modules sharing a single database for FHIR Resource storage; in which case, one should enable the Suppress Scheduled Maintenance Jobs property on all but one of such FHIR Storage modules.
Descriptions of the available settings to enable and disable these tasks can be found at Storage Module Scheduled Tasks.
If you wish to take advantage of native RDBMS database replication which creates read-only replicas, you will need to configure the read-only FHIR Storage module with Read-Only Mode Enabled. In this mode, the job scheduler is disabled entirely.
The following diagram shows a Smile CDR cluster with a writeable node and a read-only node using database replication. In this diagram, each of the nodes can be scaled independently, using as many node processes as needed. The Read-Only Mode Enabled setting should be enabled on the read-only node.
When using a node in read-only mode, it is still required to have a non-read-only node as well with at least one process active, even if this node is not actually serving FHIR client requests. This node is required in order to ensure that scheduled background jobs are executed.
After upgrading the Smile CDR server, any nodes that are in read-only mode will not attempt to automatically migrate the database to the latest version. They will however validate that the underlying database schema matches the version of the Smile CDR application. This means that read-only database schemas must be upgraded in some other way, either via replication from the writeable node, or by manually upgrading the read-only node using smileutil: Migrate Database.
Note that this setting will not prevent the server from attempting write transactions in response to FHIR operations such as create and update. This setting is intended to indicate to Smile CDR that connections to the RDBMS will always be read-only, it is not intended to enforce read-only behavior on a writeable database. If you need to ensure that write requests (e.g. FHIR create, update, etc.) are directed to the appropriate node processes, the FHIR Gateway module can be a useful component in your architecture.
Once you have selected your module type, the first set of configuration options will be the relational database configuration itself. A complete reference of options is found on the Database configuration page.
Most importantly, you will need to configure the following properties:
The Lucene FullText configuration sets up the local filesystem to use for indexing. A complete reference of options is found on the Lucene FullText Indexing configuration page.
Most importantly, you should configure the following property:
The configuration options available for this module type are as follows: