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 of OpenIMIS.
OpenIMIS is built modular "from the core on": even central features (like Insurance Scheme management) are built as a module of a core platform.
The core platform provides generic components (building blocks) to be used by / particularised in the various modules and is split in 3 layers:
- Frontend(s) layer
- Backend layer
- Database layer
Frontend(s)
Modularity at frontend layer is achieved by assembling (UI) components in various technology stacks:
- web-application
- mobile application
- plugin of other platforms (DHIS2 app)
OpenIMIS FE core provides:
- building blocks to address topics such as:
- I18N
- standard types components (like period selection, amounts,...),...
- generic technical components (like confirmation dialog, user notification, error handling,...)
- transversal features related to:
- User & Security (login, profile, roles,...)
- Menus
- Job scheduler
- Administration (install and configure modules,...)
Each OpenIMIS FE module is standardised to
- expose (and register to) contribution points
- provide components for managed entities (claim picker, claim "row" representation,...)
- allow built-in or overloaded extensibility
Backend (api)
Modularity in backend layer is built around an (internal) bus, where modules emit and subscribe to events.
OpenIMIS BE core provides:
- building blocks to address topics such as:
synchronous/asynchronous messages (events) to/from other Software components and other OpenIMIS modules
- transversal features related to:
- User & Security (login, profile, roles, audit,...)
- Job scheduling, monitoring,...
- Transaction and error management
Each OpenIMIS FE module is standardised to
- expose (automated) REST Api (aligned to DHIS2 way of working?)
- allow built-in or overloaded extensibility
- implement ORM and database migrations
Database
OpenIMIS is based on a relational database, with enforced good practices:
- instance-agnostic id (UUID)
- managed indexes and foreign keys (even cross-modules!)
OpenIMIS is NOT
- multi-tenant