• Getting Started
  • 2.0 Basic Concepts
  • 2.1 Platform Requirements
    • 2.1    Platform Requirements   
       Table of Contents

    Basic Concepts

    2.0.1Basic Concepts

     

    Welcome to Smile CDR! Before getting started, let's spend a few minutes going over the basic concepts of how the software works.

    2.0.2Nodes and Modules

     

    A Smile CDR deployment is divided into nodes and modules.

    • A node is a single server process that runs on a server, and is executing the Smile CDR service (e.g. as a Linux daemon or as a Docker container)
    • A module is a Smile CDR software module running within a node that handles a specific piece of functionality

    Each module in a node has its own configuration, and performs a specific function within the CDR. As an example, the simplest version of a FHIR server built with Smile CDR would consist of several modules, including:

    • A FHIR Listener module – that has been configured to listen on a given port, has TLS/HTTPS settings, security settings, etc.
    • A FHIR Storage module – that has been configured with database settings, that handles saving and retrieving resources, etc.
    • An Inbound Security module – that handles authenticating incoming requests

    The following diagram shows a simple example of a server with a single node containing several modules.

    Nodes and Modules

    2.0.3The Cluster Manager Module

     

    Every node has at least one module: the cluster manager. The cluster manager module is present even if you only have a single node (non-clustered deployment). It handles most of the basic bootstrap functionality of the system, including loading and saving module configuration, starting and stopping other modules, performance metrics tracking, health checks, etc.

    2.0.4Module Dependencies

     

    Within a node, a module can depend on other modules for functionality it needs. For example, the FHIR Listener module – that exposes an HTTP REST endpoint to which clients can connect – needs:

    • A FHIR Storage module – that has been configured with database settings, that handles saving and retrieving resources, etc.
    • An Inbound Security module – that handles authenticating incoming requests

    There are different types of modules that can satisfy dependencies between modules. For example, the required Inbound security module might be a Local Inbound Security module, which is a security module that saves user accounts in Smile CDR's own database (including salted password hashes) so that users can be authenticated without needing to connect to an external user database. On the other hand, it could also be an LDAP Inbound Security module, which delegates password checks to an external LDAP directory.

  • Getting Started
  • 2.0 Basic Concepts
  • 2.1 Platform Requirements
    • 2.1    Platform Requirements