On this page:

21.0Database Design


Smile CDR typically uses two separate databases (i.e. sets of tables) in order to operate. These databases are outlined below. Conceptually these are separate sets of tables with different purposes.

In a simple installation it is possible for all tables to exist in a single database schema, which will simplify deployment. However, unless you know that your requirements will remain small, it is recommended to create separate database schemas for each set of tables.

21.0.1Cluster Manager Database


This database is required in order for Smile CDR to operate. A single instance of this database must be shared by all nodes in a cluster. This database is used to store:

  • Node and module configuration for all nodes and modules across the cluster.
  • Runtime metrics about usage and health of various nodes across the cluster.
  • User accounts, including salted-hashed passwords if the Local Inbound Security module is being used. If other security mechanisms such as an external Active Directory are being used then a placeholder entry is still created in the cluster manager database in order to link transactions, audit records, etc. together.
  • Transaction logs stored by the system.
  • Audit logs stored by the system.

21.0.2FHIR Relational Storage


This database is used to store FHIR resource contents. A typical installation will have one instance of this database, which is shared across all nodes in the cluster. In such a configuration, FHIR clients accessing Smile CDR will see a single endpoint with a single pool of resources.

However, depending on your specific requirements, you may want to have multiple separate and distinct pools of resources. If this is required, you may want to create multiple FHIR Relational Storage databases – and multiple FHIR Storage (Relational) modules pointing to them.