FHIR Storage (Relational) Module
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.
Details on the database schema for the FHIR Storage (Relational) module can be found in the HAPI FHIR Documentation. Initialization scripts can be found in the Database Administration section.
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 Smile CDR Nodes sharing a single relational database schema instance 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.
An example of such a configuration would be a deployment with a dedicated read node (and processes) and a dedicated write node (and processes). This could be done in order to scale read/write functions separately. In this case you might wish to perform scheduled tasks on the write nodes in order to keep the read nodes free for public traffic.
Descriptions of the available settings to enable and disable these tasks can be found at Storage Module Scheduled Tasks.
Response: Generally speaking, the only real limitation is for fields that you want to index for searching. So for example, the length of Observation.note is effectively unbounded. The full resource body is temporarily stored in memory, so there are practical scalability limits if you had massive strings (ie multiple megabytes) and lots of concurrency, but other than that there is no limit.
However, in the case of fields that are indexed for searching the indexer may impose a maximum length on the field. For example, Patient.name.family will be indexed because it has a search parameter by default. The maximum length for string indexes is 200 characters.
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: