...
enrollment
Insurance product:
the principle of insurance product is to enroll Beneficiaries via a contribution hat that the insurees pay themself, this means that the main insuree is entering in a contractual relation with the scheme, to do so they accept to comply with the conditions, this include, but not limited to a serie mandatory information on the insurance taker (Head of family) and other beneficiaries.coreMIS
social protection program:
unlike openIMIS product, coreMIS program aim to the target people proactively based on politic impulse, this mean that the program need to have a base of potential beneficiaries (high probability of errors in the data) used to target the final recipent for the relief based on the relief target
data models
Persons and groups
openIMIS insuree models (with family, photos etc ) were too restrictive to use it with coreMIS (to many data constraints) therefore Individuals and the Beneficiary models (with group) were created
the main difference is that the social protection individual has almost no mandatory fields but first_name, last_name and dob
Program/product
Insurance product is packed with historical configuration that are for most completely useless in the scope of social protection programs
How to merge those fundamental difference ?
I do believe that once a person is enrolenrolled, some confidence in the data collected must be correct there for the “beneficiary“ must use the same table as “insuree” (Beneficiary being more generic)Also the relationship entity that reflect the enrolment should be similar, in openIMIS product, we use a policy but it is too limited for coreMIS, something more generic is required: “Benefit”. also the individual module bring an new concept that can be reused for Practitioner and other “individual“ that may not have a login.
To replace Insuree with Benficiary: I believe a wrapper class should be created in a first place to use beneficary instead of insuree in every part of the code but the database will still require to be migrated
TDC, a mandatory schema could be added to the Beneficiary additional fields to ensure coherence of the data, a “legacy insuree schema“ should be created
Social protection benefit plan should move toward , openIMIS product should move to the benefit entity in the future.: Benefit consumption module / EnquireBefore being a beneficiary, for targeting reasons, a person will be an individual/person, this model will require up to no mandatory data. and policy to Benefit consumption module / Enquire , the hardcoded limits in the Social protection benefit plan should be mode to validity strategy of the cash benefit