Target (modular) Architecture

This page provides a high-level (introduction) view of the openIMIS targeted (modular) architecture.

The transition (transformation) plan from current (2018) openIMIS implementation to this architecture is described in a separated page: Modular Transformation.

Modularity Levels

Modularity (and its integration counter-part) is considered at 3 distinct levels:

  • Solution level, considering the solution as a coherent assembly of Software Components, like Client Registry, Shared Health Record system, Universal Health Coverage,...

  • Software Component level, where components are decomposed into (activated or not) modules dedicated to fulfil the expected scope for them  

  • Entity level, where each concept hosted by a Software Component can be particularised to the specific needs of an implementation.

Solution level

At Solution level, the roadmap clearly position openIMIS as a component of OpenHIE platform.

The expected modularity at that level is achieved by:

  • conforming to the OpenHIE platform standards (enforced via the OpenHIE Integration Layer)

  • adopting the FHIR existing standards to expose openIMIS - managed concepts

Software Component & Entity levels

Software Component and Entity levels modularity are fully in the scope (controlled by) of openIMIS.

openIMIS is built modular "from the core on": even low level features (like login,...) and central features (like Insurance Scheme management,...) are built as a plugins of a core platform.

The core platform provides generic components (building blocks) to be used by / particularised in the various plugins and is split in 3 layers:

  • Frontend(s) layer

  • Backend layer

  • Database layer

Although openIMIS is an assembly of components (themselves assemblies of plugins), deployments of openIMIS doesn't impose a distributed deployment.

The choice of isolating the various (server-side) components to dedicated infrastructure is taken according to each project's needs.

Within a project, scaling up by distributing components as the load increases is a very standard (and easy) operation:

Further Links

https://openimis.atlassian.net/wiki/spaces/OP/pages/586448901

https://openimis.atlassian.net/wiki/spaces/OP/pages/586285073

https://openimis.atlassian.net/wiki/spaces/OP/pages/586612753

openIMIS is NOT

  • multi-tenant: while database table will receive a tenant-discriminant (index) column, being multi-tenant requires several precautions we are not going to address in early project phases (like computing/ IO resources sharing, forced coordinated upgrades,...)