...

Individuals / Groups / Beneficiary module and program

determining MVP for this project (from WorldBank team perspective):

• beneficiary

• reporting

• payment

Moreover GRM module is also important and this is also a requested feature.

Determining the term of Individual (Beneficiary etc) and Group (could be Household or another kind of group). Collecting data related to relationships in Household etc.

Grouping is not always the household. In terms of new program it should be individuals and groups. Group is also presented in FHIR approach when it comes to the terminology.
Replacing Family by Groups idea in openIMIS. The same for coreMIS - Household into Group.

Match people / individual to the specific program. Applicant would be a beneficiary in specific program. We have different rules to assign beneficiaries. The status is related to the specific program. You can be graduated in specific program and active in another, you can be suspended in particular program but active in second one. Therefore individual could be assigned to different program based on status.

Group could store such information regarding the owner of benefit ect (for example about PolicyHolder, main member of household/family). We could think about flag to mark whether we need consider such data or not (data could be for example not be up to date).

Beneficiary with 'active' status is a person who has the active benefit and may take the advantage of such fact. Beneficiary subscribe particular program with particular benefit for example cash transfer. It is possible also that Beneficiary could subscribe two active program.

The biggest challenge in developing module is the filtering that need to be developed.

Allow user that created coreMIS instance/program particular fields used in models - simply to determine the definition of Beneficiary. We have structured data in openIMIS, but we have json_ext to allow add something extra to models in standard database approach.

Recipient must be added in scope of Group etc.

Beneficiary update - separate entity is created called BeneficiaryUpdate and such entity could be either accepted or rejected - such feature also need to be developed on openIMIS level.

Individuals / Groups / Beneficiary module & data updates (cont.)

Policyholder:

Policyholder is a kind back office worker responsible for managing benefits

Contract could need the proof that people know about being part of such Benefit for example signature/document with signature/fingerprints ??

Possible new approach for the individuals in the openIMIS:

• Currently we use “Individuals” in as a part of multiple components; users, insurees, etc.

• We could extract it as a separate entity that would be shared between different components.

• When we have different id’s and we cannot trust them then perhaps those could be put in different spaces.

To be checked: How FHIR handles duplicates?

Incoming data approach:

• Minimum data (name, surname, dob + other minimum person data according to the standards)

• Extra data - unstructured information

• callback

It could be good to have parallel ETL configuration for different programs

Reporting and dashboard (Kibana - Open Dashboard and OpenSearch)

Discussing strategy for migrating packages from both systems.

• the first stage - separate systems that need to be integrated and checking for similarities between those systems (now)

• second stage - two scenarios:

  • pure openIMIS version: whenever the migrated modules in openIMIS fulfill the needs of the new use-case, openIMIS is used

  • hybrid version (intermediary): migrated openIMIS modules packaged together with not-yet-migrated CORE-MIS modules in new CORE-MIS distributions

• third stage - new openIMIS technology stack combines all openIMIS and all coreMIS functionalities (maybe with a different branding/package/distribution) (future)

Determining the day of turning off using old systems to use new one. (cut off supporting and development of old ones) Especially important in terms of regular releasing.

Worldbank is maintaining an up-to date hybrid version of the most recent releases on an openIMIS demo server instance.

Reporting - openSearch (mentioned in yesterday’s meeting notes) or Kibana or another openSource solution (important when it comes to the licenses)

Statistics are related to particular programs. Time Filters: monthly, daily, quarterly, every half year, yearly etc by default ??

• how many beneficiaries are registered in particular program within particular period of time?

• Some data necessary for statistics and measures are retrieved from external systems.

• it could be good to determine which fields should be mask in terms of security reason (data anonymization) to engine reports by anonymous data.

Superset also could be considered as a reporting tool. Easy to embed dashboard into system, possibility to extend by additional plugins. The way of handling reporting stack: separate db (it needs additional ETL process to load such data) or having the same database.

Does Kibana contain connection to the core-MIS database or does it have connection to another reporting db? (question to Malik).

• Kibana has separate database connection and not connected to mongoDB - there is connection to ElasticSearch.

• There is separate workflow to load data into elastic search on coreMIS level. There is cron job that load data - two cron job daily in the nights depends of timezone of clients.

Creating indexes -advantage: improving performance, drawback: memory consuming

How the cube data are created?

• by performing some updates through pipeline process.

• spark could be between main database (mongoDB) and ElasticSearch db

Elastic Search - problem with licenses (need to switch to free one). Elastic Search now has more restricted version since particular version of this software is released hence coreMIS uses specific version with more open license.

OpenSearch dashboard - possible to write basic query to visualize particular field of business point.

Considering Pivot table in openSearch and Kibana etc (also in ‘FlexMonster’ software). Such feature could be really useful to create and select properties for particular Pivot table.

We should also be careful when it comes to the limitation of localization in researching data. It could be necessary when we will develop Oauth mechanism in reporting stack to have possibility to automatically log in in target external system.

We have possibility to add and define additional filters in dashboards in Kibana (and openSearch - TBC ??)

openSearch is probably the best choice for new reporting tool in terms of coreMIS openIMIS integration.

Location management

Question regarding managing level of localization in the openIMIS. It is fixed - we have always four levels of localization. It is in one table:

• region

• district

• municipality (wards in some implementations)

• village

We don’t keep latitude/longitude data on location level in the openIMIS. Now is not possible to extend the number of localization levels in the openIMIS. This could be a challenge to change this in current implementation.

Multi location requirement (for example beneficiary from three or more different villages ) . You can group people for certain activities.

Payment

We can calculate base on the figures in the system when it comes to the payment amount. Taking photo etc (proof of payment - mentioned in yesterday’s session).