Deployment models represents represent a specific type of deployment of Telemedicine Solutions..

• Single Page Application (SPA) or server-side generation of web pages

• All logic in browser or server-side components such as BFF

• Using the KAM micro frontend architecture

• Thick clients such as native mobile applications

• etc.

There are several way ways to develop and deploy Telemedicine Solutions:.

Single page application

The server returns a single page that is manipulated in the browser using e.g., JavaScript API. The content of the single page based on calls to eHealth services from the browser.

Applications may be simple One of the simplest types of applications on the eHealth Infrastructure is to develop a single-page application.

The application may be a simple web server (delivering web content to the browser) delivering a single page to the browser.

The application may be hosted on the infrastructure.

The browser is then requesting requests data from backend, and updating the eHealth services and updates the single page based on the content returned from the eHealth services.

If no logic is needed then a simple application serving web content to a browser is perfect. E.g. just a simple web application hosting a single-page app based on Angular and typescript in the browser.

...

...

Applications using a BFF

...

The "Telemedicine Solution" is split into two

• a front-end (UI) that serves as Singe-Page Application (SPA).

• a backend/backend-for-frontend  (BFF)

The Singe-Page Application is executed in the browser and requests data from backend-for-frontend, which provides an API optimized for the application.

BFF is a variation of the API gateway pattern.

...

The BFF acts as a single entry point for

...

BFF provide specific backend have one backend per user experience (Instead have a general-purpose API backend)

The BFF handles the application and provides a single backend for all eHealth services,

The BFF may handle requests in one of several ways.

• Some requests are simply proxied/routed to the appropriate service.API gateway converts proprietary requests and responses to FHIR exposed by the Infrastructure

• API gateway maintains data consistency across multiple services  

• API gateway handles other requests by fanning out to multiple services (orchestration/choreography)

• API gateway maintain data consistency across multiple services  

• API gateway converts FHIR request and responses to proprietary protocolSome requests are simply proxied/routed to the appropriate service.

• ….

...

Applications

...

use FUT/KAM micro frontends

The clinical administrative module named KAM application (CAA or KAM in Danish) is built as an application with individual a micro-frontends, that are integrated frontend application, meaning the KAM elements can be integrated into an application in the browser.

KAM has a number of endpoints where several services and endpoints which the browser can retrieve KAM components from. Currently it KAM consists of the following components:

• common workplace ,- frame for the different micro-frontends

• careteam , micro-frontends

• questionnaire editor micro-frontends,

• the plan template editor micro-frontends and

• pickers .

...

• micro-frontends

...

• .

KAM elements are then put together in the browser. That is, the user will download an application consisting of five components, which will run in the browser and will send request requests to the eHealth services

...

Server-side generation of the web pages

The Telemedicine Solution is hosted on the eHealth infrastructure and generates web pages on the server based on requests from the browser.

The Telemedicine solution is hosted on the eHealth infrastructure that generate web pages. The browser is then requesting browser requests data / new pages from the Telemedicine Solution. The application generates new pages on the server by requesting data from eHealth services.

...