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:
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:
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,...)