Page Comparison

• Target (modular) Architecture

  • https://openimis.atlassian.net/wiki/spaces/OP/pages/586448901/Frontend+s+Target+Architecture

    • openIMIS Web FE Architecture

Describes “Modularity” as

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.

…

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:

Plugins are documented in openIMIS Modules.

openIMIS Modules

In openIMIS, (nearly) everything is a module: even "low level" (and mandatory) features follow this principle.

…

Plugins (can) provide several types of archetypes, dedicated to the various openIMIS layers: openIMIS Mobile FE, openIMIS Web FE, openIMIS Online BE, openIMIS Batch BE,...

openIMIS can be deployed with an extra layer dedicated to implement a FHIR API, based on openIMIS core (base) modules.

Patrick Delcroix in the comments:

Here my point of view on the module list details in 4 groups (core, business...)

The module with * leading are not found in JLN

IT core

• *Core & security
  

  • Database access,

  • Logins, user, roles including enrolment office & claim admin,

  • Email

Business

• Claims Management
  

  • Claim,

  • Feedback,

  • Review

  • Appeal (not available)

• Scheme Policy
  

  • Insurance companies (not available), 

  • provider policies settings,

    • Product

  • Eligibility Requirements,

    • Product

  • Benefit Package Formulary

    • Product

  • provider rates

    • Price lists (Item and services),

  • Funding

• Premium Collection ,

  • Payer

  • Policy payment

• Beneficiary Management

  • Insures,

  • Group,

  • Policy,

  • Renewal

Register

• *Locations (regions … )

• Provider Management

• *Client registry

• *Medical item

• *Medical Service

• *Diagnosis

Reporting

• Performance Management

  • Statistics and reports

Background - Joint Learning Network for UHC

The JLN Process Matrix

JLN Process - OpenIMIS Mapping

• Background - Joint Learning Network for UHC / The JLN Process Matrix

  • Business view (sector specific)

  • Seems outdated (2012)

• JLN Process - OpenIMIS Mapping

  • Does name but not link to “openIMIS Modules” / “Proposed modules”

  • Seems outdated

    • Refers to Legacy & Modular

    • Refers to old releases (no changes in between?)

  • Seems incomplete / contains questions

  • Has draft of property table & module structure

Sources Release 2022-10

• Single repositories were named “Module” now “Component”

  • Not all repositories contain source code, some are used for databases, package linkage, docker scripts etc.

openIMIS Management Console

• Refers to frontend and backend “Modules