On this page:

2.1Platform Requirements


This page lists requirements for installing Smile CDR. This applies only to self-hosted versions of Smile CDR. If you are using a cloud-hosted version then this page does not apply.

Note that these are the requirements that are known to work with Smile CDR. If you have other requirements in mind, they may work as well. Please contact us to discuss other options.

2.1.1Server Requirements


The following list defines the minimum server requirements for a server hosting Smile CDR. Smile CDR may be configured in a 1-node cluster if high availability is not needed, but 2+ nodes are recommended for better reliability.

  • Environment: Smile CDR may be installed to physical or virtual servers, or to Docker containers.
  • CPU: A 2-core X86-64 CPU (required); 4-core X86-64 CPU (recommended).
  • Memory: At least 4 GB of available RAM is recommended.
  • Operating System: Deployment on GNU Linux is recommended. Ubuntu and RHEL/CentOS are both known to work, but other distributions are likely also fine.
  • Disk Space: Smile CDR requires an environment with at least 10 GB of free disk space. Note that large installations with FullText indexing enabled will require significantly more.
  • Database: Smile CDR can be used with any of the database platforms listed below.

2.1.2Java Requirements


Smile CDR is supported for use against one of the following distributions of Java:

  • OpenJDK 16.0.1+ or Oracle JDK 16.0.1+ (Recommended)
  • OpenJDK 11.0.1+ or Oracle JDK 11.0.1+ (Supported)
  • Oracle JDK 1.8.0_121+ (Supported)

Smile CDR will run against a simple JRE (compiler tools are not required in order to use Smile CDR) but the JDK comes with many tools which can be useful for troubleshooting issues (e.g. jstack, jmap, etc.)

Smile CDR may also work correctly against other distributions of Java (OpenJDK, IBM JDK) but these are not well-tested and are not recommended. Note that you can skip the Smile CDR minimum Java version check by adding the argument -Dskipjavaversioncheck=true to your setenv file.

2.1.3Database Requirements


Smile CDR requires a relational database to use as a store for system data, such as configuration. A relational database or non-relational database can be used to store FHIR resource information.

Relational Database

The following database platforms are supported:

  • PostgreSQL 9.4 / 9.5 / 9.6 / 11.4 / 12.2
  • MySQL 5.7
  • MariaDB 10.1
  • Oracle 12c R2 / 18c / 19c
  • MS SQL Server 11 (2012) / 12 (2014) / 13 (2016) / 14 (2017)

Smile CDR also supports the following embedded database platforms, generally used for testing:

  • Derby
  • H2

Non-Relational Database

The following database platforms are supported:

  • MongoDB 4.2

Support for Database Versions Not Listed Here

Listed database versions have been tested and certified to work with Smile CDR. We have every expectation that more recent versions, particularly point versions will work seamlessly with Smile CDR. We do encourage that non-listed RDBMs versions be tested in a non-production environment prior to going into production. As part of our standard professional services engagement we are happy to provide that testing or to suggest a testing methodology.

Support for AWS Secrets Manager JDBC Connections

The following databases are currently supported for authentication via AWS Secrets Manager: MariaDB, MSSQL, MySql, Oracle, Postgres

To use the AWS Secrets driver set the following DB properties (Postgres use case shown):

  • module.clustermgr.config.db.driver=POSTGRES_9_4
  • module.clustermgr.config.db.secrets_manager=AWS
  • module.clustermgr.config.db.url=jdbc-secretsmanager:postgresql://<db-host>:<db-port>/<db-name>
  • module.clustermgr.config.db.username=<your-defined-secret-name>
  • module.clustermgr.config.db.password=<any-non-blank-string>

Also add the following environment variables:

  • AWS_ACCESS_KEY_ID = Yous AWS account access key ID
  • AWS_SECRET_ACCESS_KEY = Yous AWS secret account access key
  • AWS_REGION = The AWS region where your secret is defined

The following steps will help you replace a regular JDBC connection string with an AWS secrets manager JDBC connection string:

  1. Add the property: secrets_manager 2. Replace the jdbc segment of your UL with: jdbc-secretsmanager.
  2. Set the name of your defined AWS secret as your username.
  3. Set any non-blank string as the password (is not used, but can't be blank).
  4. Set the appropriate AWS-related environment variables.

2.1.4Network Infrastructure


Smile CDR is a full featured HTTP server and is capable of directly serving client HTTP requests. It is not necessary to pair it with other network infrastructure. However, there are several other network technologies that can be combined with Smile CDR in order to achieve specific architectural goals.

The following three examples list potential network infratructure components that can be paired with Smile CDR. Note that these are not completely separate concepts: A single piece of software (or hardware) may actually perform any or all of these functions.

Load Balancer

Smile CDR clustering (i.e. of FHIR/REST endpoints, Web UIs, etc.) can be set up in a horizontal fashion using a variety of topologies. These include Acitve/Active and Active/Passive setups.

When configured in a typical Active/Active configuration, incoming HTTP requests may be distributed in a completely arbitrary (e.g. round-robin) or a predictable way (e.g. sticky-session). Smile CDR clustering makes no assumptions that multiple requests belonging to the same user session or OAuth2 token will be delivered to the same physical endpoint, so clustering can be easy to set up.

Load Balancers may be a purely software software solution such as NGINX or may be a hardware or cloud infrastructure device.

Reverse Proxy

A common configuration option is to place a reverse proxy such as NGINX or Apache HTTPd (with mod_proxy). The use of a reverse proxy typically fulfills one or more of the following functions:

  • Serving Default Ports: Smile CDR should not be run as root, meaning that on a Unix system it is unable to bind ports 80 or 443. Using a software proxy allows Smile CDR endpoints to be visible on these default HTTP/HTTPS ports.

  • TLS Termination: It is possible to configure Smile CDR to serve TLS (i.e. https), but it can sometimes be beneficial to use a software proxy to serve TLS "in front" of Smile CDR. This is because a dedicated software proxy can typically restart effectively instantly, meaning that certificate changes can be performed without any noticeable downtime. This is especially useful when using short-lived certificates, such as those isused by LetsEncrypt.

  • Endpoint Consolidation: Smile CDR serves each endpoint module on a separate port. Using a software proxy allows multiple endpoints to be served on a single port using different root paths to separate them. See Specifying a Custom Context Path for more information.

API Gateway

API Gateways are popular tools in modern RESTful architectures. An API gateway typically provides several functions. Some of these functions can be provided natively by Smile CDR, meaning that a separate gateway is not necessary. Other functions require the use of a dedicated gateway.

  • Centralized Service Security (e.g. a common authentication scheme such as OAuth2 or HTTP Basic is applied to all services provided by the gateway)

Smile CDR can handle authentication and authorization of users entirely within its own security layer. The security services, including the OAuth2/SMART services are designed to be aware of FHIR data and REST patterns, meaning that Smile CDR can provide a nuanced security implementation that would be difficult or impossible to design using a standard API Gateway alone.

Smile CDR can be paired with a Gateway product however. This pairing can involve the Gateway handling user the authentication and authorization. This pairing can also put authentication and authorization decisions in both layers (i.e. in both the Gateway and in Smile CDR) for a defense-in-depth strategy.

  • Monitoring

Smile CDR can also be configured to keep detailed metrics on service utilization and performance. There are advantages however in maintaining an external monitoring tool that can raise alarms when key performance metrics fall below predetermined thresholds.

  • API Key Management

Smile CDR does not currently have the ability to manage API keys.

]: /docs/configuration_categories/database.html#property-db-secrets-manager]