Architecture of Clinical Administrative Module (Danish: Klinisk Administrativt Modul aka KAM)

As an extension of the infrastructure, a front-end for certain FHIR microservices has been built into the infrastructure. The solution is built to be an administrative solution for administrative tasks. The solution uses the existing security model of the FUT infrastructure and the resources of the FUT infrastructure. A user accessing this solution needs to have administrative privileges for the areas of questionnaires, care teams, plan definitions, and activity definitions. A user with access rights to this solution does not automatically gain access to the clinical or the SSL domain.

The page describes the architecture of these frontends, developed as micro-frontends see also: Micro Frontends (martinfowler.com). The integration model used here, and also described in the document by Martin Fowler is the “Run-time integration via Web Components”.

User story using a shell application as a micro frontend

To understand the architecture, it is important to understand the concept of micro-frontends. This can be shown by showing how a user is presented with the KAM solution:

1. When a user accesses the KAM frontend, they are accessing a web application (single page app or SPA) like this:
   
   

   Open

   

2. Here they can push the green button to log on using the FUT infrastructure IdP, like this:
   
   

   Open

   

3. After login, they are presented with a selection of the security context they would like to use in KAM. This selection will determine the set of micro-frontends they have access to.
   
   

4. After this selection, the user can use KAM and its modules with the individual micro frontends. This is shown below:
   
   

The KAM solution is here composed of a shell application, which shows micro-frontends inline.

The shell application in this screen dump is:

• The top bar, with

  • main navigation links

  • security context selection

  • log off functionality

• The left menu bar gives the user the possibility to

  • select different micro-frontends like careteam and questionnaire

If the user selects the careteam in the left menu, the user is presented with this:

The table listing the careteams (the grey area on the screen) is a separate micro-frontend that is assembled by the browser within the shell application. This micro frontend is a separate component in the FUT infrastructure but is assembled by the shell application for the user. Now that we have a basic understanding of the roles of a shell application, an identity provider (IdP), and a micro frontend, we can have a look at how these have been deployed as individual components in the FUT infrastructure.

The component model of the KAM architecture

To describe what has been built and deployed, and how the components interact, we will start with a diagram with the two main areas of components in the FUT infrastructure cluster. All components are still packaged and released as containers, as every other component on the infrastructure.

In there, we have four types of components all released as containers.

The four types of components are related in this way:

• The shell frontend (kam-ui) is a web application where the micro frontends are exposed inline. To the user, it seems to be one application.

• The micro frontends are using the common pickers, to look up organizations, terminology, etc.

• The micro frontends are using the infrastructure services to look up and persist resources in the infrastructure.

The four components are further described here:

• Shell frontend

  • The shell frontend is a single-page app. It handles security and routing to the individual micro-frontends. The user accesses the shell and from there they can navigate through a menu to the individual micro-frontends. The user never leaves the shell application, but different micro-frontends can be shown. The connection between the shell application and the micro-frontends is very loosely coupled, and only through the user's browser. For further information on micro frontends see https://micro-frontends.org/. The shell application is hosted as a container with an Nginx server, to enable the browser to load the shell frontend. The shell frontend-only really runs in the user's browser. The way these micro-frontends are loaded into the shell application is facilitated by the tool Webpack, see also Micro frontends - eHealth Infrastructure Wiki - Confluence (atlassian.net) and Concepts | webpack

  • The micro-frontends are not loaded before they are needed, in order to maximize the performance of the user experience. As there can be many micro-frontends pre-fetching would come with a bigger and bigger penalty.

• Micro frontend

  • The micro-frontends expose a frontend, tailored to show resources from a single infrastructure service. Currently, there are three micro-frontends: careteam, questionnaire, and plan. These micro-frontends are exposed by the shell-frontend and use infrastructure services to deliver resources to the end-user. For more information on how to interface from micro-frontend to shell application, read this page: Micro frontends - eHealth Infrastructure Wiki - Confluence (atlassian.net).
    The individual micro frontends are hosted as a container with each their Nginx server, to enable the browser to load the specific micro-frontend. The individual micro-frontend only runs in the user's browser.

• Common pickers

  • Among the micro-frontends, there is a need for a shared set of pickers, to make it possible to select an organization, create a timing expression, set measurement thresholds, etc. For this, a module has been created. The micro-frontends include this module and invoke it using messages in the browser, and will also receive the picked value/setting through a message. For more information on how to utilize pickers from the KAM project, have a look here: Kam-pickers - eHealth Infrastructure Wiki - Confluence (atlassian.net). The set of pickers is hosted as a container with each its own Nginx server, to enable the browser to load the pickers. The pickers only really run in the user's browser.

• Infrastructure services

  • The remaining services are all infrastructure services

Dynamic interaction between the KAM components

To better understand this have a look at this sequence diagram:

In this sequence diagram, several details have been omitted, among these is the complex setup behind the logon process after the user hits the IdP, with redirects to the local IdP via SEB.

As an example, we can have a look at the usage of the careteam micro frontend and its usage on the FUT infrastructure.

Security model

The security model used in KAM is the same as the one used in the remaining FUT infrastructure. This means that the shell application will redirect the user to the IdP using the user's browser, and in this process receive a set of security tokens (JWT). The shell application has the responsibility to do the required refreshes to ensure that the tokens are valid at all times when using KAM. The access token is provided to the micro-frontends in the browser’s local storage (with access tied to the KAM domain). They can use the token to do lookups into the infrastructure, and thus will only present data, which the current user has access to, with the currently selected security context.

Extensibility

The model used for micro-frontends is flexible and has already, apart from KAM been used by the K-PRO project for administrative elements. This is shown by this:

Here we see two new menu items, each linking to a separate K-PRO micro frontend:

• “Fortolket visning” which enables the setup of views with interpretations of collected data from questionnaires

• “Handlevejledninger” which enables the maintenance of instructions for different measures, carried out based on questionnaire results

This setup is possible by mere configuration of the common workplace, with the configuration of new menu items with associated security model.