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.
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.
Smile CDR is a Java application and requires a Java Virtual Machine (JVM) or Java Development Kit (JDK) installed. This is not required when using the Docker distribution of Smile CDR, since that distribution includes a JDK.
Smile CDR is supported for use against one of the following distributions of Java:
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.)
There are many available distributions of the Java Virtual Machine (JVM) and Java Development Kit (JDK). These include AdoptOpenJDK, Azul Zulu, Amazon Corretto, and RedHat OpenJDK. These distributions are all based on the same core OpenJDK codebase, but each vendor may add additional patches and fixes.
We recommend the Amazon Corretto JDK.
Smile CDR may also work correctly against non-OpenJDK distributions of Java (e.g. IBM J9 JDK) but these are not well-tested and are not recommended.
You can skip the Smile CDR minimum Java version check by adding the argument
-Dskipjavaversioncheck=true to your
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.
The following database platforms are supported:
Smile CDR also supports the following database platforms, generally used for testing:
The following database platforms are supported:
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.
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):
Also add the following environment variables:
The following steps will help you replace a regular JDBC connection string with an AWS secrets manager JDBC connection string:
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.
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.
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 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.
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.
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.
Smile CDR does not currently have the ability to manage API keys.