Minutes of the Main workshop: 2023-05-08 - 2023-05-12 openIMIS/CORE-MIS Developers Workshop

Lifecycle of the social protection program in the CORE-MIS

Single program can have multiple provisions, like:

• Services (Trainings, Savings Groups)

• Cash Transfers

• Goods

Question:

• How chaining work?

• If different provisions are done in scope of project - what is the flow?

Some use cases could be:

• Paying per children in school (but payments go to the care give or even some entity in school like chief)

• Conditional cash transfers - for example person works for a week and gets paid a daily wage x days worked.

Payments are different from program to program - APIs should be easily configurable.

Services:

a) Training:

• it could be also support to pay for additional courses to improve someone's skill

b) Savings groups:

• it is done by economic reason (some people simply spent their money on consumption)

• kind of investment for group of person

Reconciliation - There are 3 reconciliation modes:

• CSV/XLS mapper to map external fields into core-MIS

• payments mobile app (offline app for Android) (PPM app for payment)

• API integration (similar to CSV/XLS mapper)

Cycle of payment and verification:

• for checking if someone still is eligible for receiving money/benefit from benefit ('Do you still need a money/benefit?').

• Such condition could be handled by national government.

GRM - Grievance Redress Mechanism

There is separate module to configure SMS campaign etc (bulk messaging) - could be map to policy notification.

Duplicates:

Passport and national id is not a good idea to check characteristics to find duplicates (in some countries such data are not created for citizens of particular country due to economic reason)

Head of the household is not always a recipient, there can be multiple recipients.

Beneficiary in core-MIS:

• could not be assigned to the household

• usually beneficiary is assigned to the household

• in terms of integrations with external system it is possible to add beneficiary without household

• it could be tricky to define the conditions for such case

• Insuree could be created within contract (extending contract created in FormalSector for insuree)

• search on additional parameters (Ali,e the current coremis search/filtering ()

Idea of Person object (contact data)

• such object could be extended to Beneficiary/Insuree
  Note: person/contact table to create, user and beneficiaries should inherit from it

Two way to registry people in coreMIS:

• migrate people from legacy system for example csv file (some countries doesn’t contain system but only files) - beneficiary upload (targeting logic not required)

• target module to find person

Beneficiary status meanings:

• Potential: person that match filter for being beneficiary

• Enrolled: beneficiary - need to meet extra criteria

• Active: have benefit and such person can receive money/benefit

• Suspended: depends of program - (there is possibility in the system to revert such person to be active again)

• Graduated: for example incompatible program (person choose different program), such person don't need ‘help' anymore, such status is to keep data for historical reason . Once beneficiary is graduated such person shouldn’t go back into such project/program.

Note: Those statuses and another new ones need to be checked in scope of checking 'lifecycle' of another objects in the system to verify if there is any affect on another objects in the system.

Note: Status is related to particular program/project

coreMIS modules in a nutshell:

Assess

• Targeting (Standard module)

• Geographical codes (Extension module)

• KoBo Integration (Extension module)

• USSD Support (Extension module)

Enroll

• Beneficiary Registry (Standard module)

• Household registry (Extension module)

Provide

• Payment & Reconciliation (Standard module)

• Goods Distribution (Extension module)

• PPM Android application (Extension module)

• timesheets (Extension module)

• training (Extension module)

• savings groups (Extension module)

Manage

• GRM (Standard module)

• Data updates (Standard module)

• Bulk SMS (Extension module)

• Programs (Extension module)

• Program staff (Extension module)

Programs module:

• list of programs that can people benefit from

• in the future this could not mean the 'target', but also automatically apply some formulas/criteria.

Program staff (looks similar to Enrollment Assistant/Officer in openMIS)

• beneficiaries followed by specialist for example 3 villages could be followed by particular person/specialist (to specific localization)

• openIMIS: geograhphical link to EO and geograhphical link for Insuree too

CORE-MIS customization and installation

core-MIS technical aspects in a nutshell:

• gitlab repository

• spring boot Java

• modular approach

• each module contains interfaces

• frontend part is (Layer pattern)

• CI/CD pipelines for deployment of each module

• each module produces docker image and jar

• hosting - depends of context , could be AWS, DigitalOcean etc

• container/package register - modules need to be deployed in order to run coreMIS

• coreModule - assembly module to run all modules etc

• such modules like 'zambia-beneficiary/zambia-bulk-messages' extends and overwrite logic implemented in core for such specific country implementation

• to run locally we need to have demo folder not empty. Malik will add on gitlab level to update this module in order to run module locally

• need to implement interface for filters on openIMIS side

Google Authenticate

• Google Authenticate 2FA auth - the staff uses this one. The web app uses this to perform some vulnerable operation like accepting payments

Frontend customization:

• frontend customization also for logos/images, possibility to change background/menu theme (separate page for managing such properties?)

• frontend in coreMIS - we can find it on every modules in ‘resources’ folder -_ templates/statics (layer pattern)

Translations:

• property file with keys and choosing language to translate

• localize is a good solution to manage translations

• good to customize also some specific languages terms like it is done for Gambia.

Approvals

• Manage approvals -> Create New approval setting (select ‘chosing right’),
  select particular users for such right) - sometimes for example payment approval two person must submit particular action (multi-user approval (multi-approval) - this hasn't been implemented yet on openIMIS side - need to be developed)
  such case similar is on openIMIS EO, review claim (to be checked?)
  to consider use case with Priority in approving (higher/lower level. )

Introduction to the modular openIMIS + Git flow, CI/CD, Jira Practices, code standards

[Link to presentation]

Reporting stack in openIMIS/coreMIS

• openSearch https://opensearch.org/ to consider as the solution for reporting stack

Tomorrow → How to make Beneficiary database/dataset as configurable as possible?

OpenIMIS : GraphQL used in between Python and React as backend and frontend respectively.
Docker for packaging