• FHIR Storage (Relational)
  • 7.0 FHIR Storage (Relational) Module
  • 7.1 Resource Storage Mode
  • 7.2 Performance Tuning
  • 7.3 Lucene Indexing
  • 7.4 Performance and Caching
  • 7.5 Chained Searching and Sorting
  • 7.6 MegaScale
    • 7.1    Resource Storage Mode   
       Table of Contents

    FHIR Storage (Relational) Module

    7.0.1FHIR Storage (Relational) Module

     

    The FHIR Storage (Relational) module is responsible for resource storage and retrieval. It stores data in two places:

    • A relational database is used as the primary storage mechanism. All resources are stored in the database and indexes are created to help in finding them.
    • A Lucene filesystem is used to provide fulltext searching capability, as well as to support some terminology service functions.

    7.0.2Preparing for a New Installation

     

    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.

    7.0.3Creating the Module

     

    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.

    7.0.4Database Schema

     

    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.

    7.0.5Multi-Node Architectures

     
    Note: Do not confuse the concept of a Smile CDR Node and a Smile CDR Process. In Smile CDR terms, a Node is a configuration set consisting of a group of modules with individual configuration and dependencies between modules. A Node can be scaled horizontally by creating multiple Processes, either running on separate VMs or as separate docker containers. Each process for a given node ID will have the same modules and configuration. A full Smile CDR cluster could have one node or multiple nodes, and can have one process or multiple processes for each node. See Designing a Cluster for more information.

    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.

    7.0.5.1Scheduled Tasks

    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.

    7.0.5.2Read Only Nodes

    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.

    Read Only Replicas

    7.0.5.3Upgrading a Read-Only Node

    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.

    7.0.5.4Read-Only Mode Limitations

    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.

    7.0.6Configuration

     

    7.0.6.1Database Configuration

    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:

    7.0.6.2Lucene FullText Configuration

    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:

    7.0.6.3Reference

    The configuration options available for this module type are as follows:

  • FHIR Storage (Relational)
  • 7.0 FHIR Storage (Relational) Module
  • 7.1 Resource Storage Mode
  • 7.2 Performance Tuning
  • 7.3 Lucene Indexing
  • 7.4 Performance and Caching
  • 7.5 Chained Searching and Sorting
  • 7.6 MegaScale
    • 7.1    Resource Storage Mode