On this page:

6.1Smile CDR Subscription Architecture

 

An overview of the Smile CDR Subscription architecture is illustrated in the following diagram:

Subscription Overview

If subscriptions are enabled on a FHIR Storage Module, then that module will create a Matching Queue and send all created/updated resources to that queue. This queue is drained by a Subscription Matching module. This Subscription Matcher module needs to be configured to point to the Storage Module where you enabled subscriptions. The Subscription Matcher module uses its FHIR Storage module to retrieve two resource types required for subscription matching: Subscription and SearchParameter. The Subscription Matcher module maintains in-memory cches of both of these resources that it updates from its FHIR Storage module every 60 seconds. A new subscription will start matching immediately on the node where it was persisted. In a clustered configuration, it can take up to 60 seconds for a new subscription to start matching on all nodes.

The Subscription Matcher tries to perform most criteria matching in-memory. When in-memory matching isn't possible, the Subscription Matcher module queries the Storage Module to determine if there's a match.

Note that subscription processing is not enabled by default. If you wish to use subscription processing in your system, you need to enable subscription processing (see below).

6.1.1Enabling and Configuring Subscription Processing

 

In order to enable subscription processing on a FHIR repository, several modules must be used together. The following diagram shows how these modules relate to each other.

Subscription Components

This diagram shows the following modules:

Cluster Manager Module

The Cluster Manager Module contains the configuration used to connect to the selected message broker.

See Message Broker for information on how to select and configure a message broker. By default an embedded Apache ActiveMQ server will be used, and this is acceptable for testing purposes but an external broker should be used in a production scenario.

FHIR Storage Module

The FHIR Storage Module can be any storage module type (e.g. RDBMS, MongoDB). In the settings for the module, the desired Subscription channel types should be enabled. For example, if you wish to support FHIR REST HOOK Subscriptions, the REST Hook Subscription Enabled setting should be activated.

With this setting enabled, any Subscription resources submitted will be automatically validated by the Subscription Validating Interceptor. This means that they will be evaluated to ensure that they have a channel type and other required fields populated, that the criteria makes sense, etc.

All resources that are submitted to the server will also be placed on the Matching Queue, meaning that they will be passed through the subscription processing logic.

Subscription Matching Module

A Subscription Matching module should be created, with a module dependency on the chosen FHIR Storage module. The Subscription Matching Module is responsible for evaluating each created/modified resource as it flows through the system for whether it matches any active Subscriptions. If a resource does match one or more Subscriptions, it will be placed on any appropriate delivery queues.

In the case of REST HOOK, EMAIL, and MESSAGE channel types, the Subscription Matching module is also responsible for the outbound delivery.

Websocket Subscription Endpoint Module

If a Subscription of type WEBSOCKET is created (and this type of Subscription channel is enabled in the FHIR Storage Module configuration), a Websocket Subscription Endpoint Module should also be created, with a depenedency on the Subscription Matching Module.

This module is responsible for opening an HTTP server which listens for incoming Websocket connections and pushes Subscription notifications to them as appropriate.