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