Developer Architecture
The Connect for Life™ application is built on top of the OpenMRS open source framework. The framework is build using Java Spring framework. OpenMRS introduces an own solution for modular architecture of the application. The modules are used to tailor the specific OpenMRS implementation to the user's needs. Each module offers a technical or a functional service that can be leveraged in the context of Connect for Life™.
The OpenMRS flexibility allows to have:
- small and simple modules which modify functions from the Core or other modules, leveraging Spring AOP, encapsulating changes specific to the specific implementation;
- modules which provide common utilities for the developers, making the development work less prone to errors and solutions more reliable;
- modules which provide full end-to-end solutions, containing new data models, APIs, pages, integrations with other systems. Although, in OpenMRS, a single module rarely provides all the functions to fulfill a complex use-case end-to-end, but that is usually solved by multiple modules working together.
Connect for Life™ is deployed as a series of modules packaged together with an OpenMRS Core application.
OpenMRS Core provides common functions of the Medical Record System application and it provides the infrastructure for the modules. Modules can be added or removed during runtime and provide new, or can modify existing functions. Compared to other solutions for modular applications, like OSGi, there are much less requirements to fulfill during the implementation of an OpenMRS module and there is more flexibility.
Community-made modules have been added to make use of existing OpenMRS functionalities.
Own CfL modules have been created to add the specific Connect for Life™ functionalities. All these modules are explained in the "Modules" menu item.
The CFL OWA module contains a new optional UI layer for the specific use of Connect for Life™.
All modules connect to one database via the Spring framework.
The presentation logic will be separated from the business logic and packaged in different OpenMRS module to decouple the internal business logic from the channels thru which this logic will be consumed. This will allow modifying and/or extending the different channels without impacting the business components, but also allow modifying the internal business logic without breaking the external facing APIs. The Connect for Life™ Distribution is split in 3 different logical layers, each layer must be independent from each other and communication is allowed only through a well defined interface.
Although, the OpenMRS framework allows to choose any web technology for it's Web Application Layer, Connect for Life™ will use React. The React Web application will consume REST interfaces exposed by Connect for Life™ Web API Layer, including REST interfaces exposed by OpenMRS community-made modules.
Most OpenMRS modules have their own Web API Layer that encapsulates the business logic. The Web API Layer will include, but won't be limited to, REST interfaces, server-side-rendered HTML pages and specialized HTTP-based interfaces.
Each OpenMRS module exposes it's own Service Layer. The Service Layer, or in OpenMRS terminology a Module API, is used by modules to communicate between each other. The Connect for Life™ modules will consume the Service Layer of the community modules and expose their own Service Layer for the next community modules.
Multiple interfaces allow different actors to interact with the Connect for Life™ Distribution. Service providers can be connected with Connect for Life™ via the Web API Layer to interact with patients using calls, text messages or WhatsApp messages. The Web Application Layer exists for the different application users of Connect for Life™. This web application works with role based access and only shows the menu/pages that the current user is allowed to see given its current role.
