Next steps in CORE-MIS Migration

Comparison

Data Model

Insuree

Individual 

Model 

Model with its dependencies

Higher Resolution Image: [LINK]

Data Fields 

Many fields in the Insuree model, such as phone, email, passport, profession, education, health_facility, marital, etc., are not needed in contexts outside insurance. Reuse this model in a different context, like for benefits or payroll, many of these fields would go unused. Overuse of (blank=True, null=True) could also make querying and analyzing the data more complicated. Number of foreign keys can result in over-normalization and lead to complex, inefficient queries and poor performance. Getting a single comprehensive view of a data record might require joining many tables, which is costly in terms of performance.

Moreover data structure field compulsoriness is not reflected on the frontend level. Several fields (chf_id, gender) are marked as mandatory on frontend but on database level they’re optional. Properties like this are essential for claim processing, however are not needed for any social protection activities. Using Insuree as a base for social protection could lead to potential data inconsistencies (e.g. in scenario where person was added for purpose of social protection and there was attempt to reuse this entity for insurance, then unexpected errors could occur). 

The Insuree model has many fields and relationships, making it quite large. Managing such a model can be challenging, as it already involves dealing with a large number of columns, each of which needs to be understood and maintained. Using insuree in another context than health protection could result in even more complexity. 

From Data Fields perspective the biggest drawback is complexity of understanding and maintenance. With so many fields and relationships and shifting requirements across the application, understanding the Insuree model and how it interacts with other parts of the system requires a significant investment of time, especially from new developers. If there were fewer fields, each only included where necessary, the model could be easier to understand and maintain.

Individual come with simplified data structures. It only includes three necessary fields: first_name, last_name, and dob (+ ones coming from HistoryModel). Addition of information is handled only by json_ext, without necessitating separate tables for each piece of data or mixing data in columns with data in json_ext (which would be the case if Insuree data structure would be kept).This allows the model to adapt to varying data requirements without needing to modify the database schema. 

Relying only on json_ext field could lead to potential data inconsistency issues because it is unstructured and validation is not enforced by the database. This means that application code would need to ensure data integrity, which could be a challenge to manage. However, from the system perspective Individual is meant to serve as an actor that will have multiple more complex personas, including but not restricting to the both Insuree and Social Protection Beneficiary, this balances the vulnerability to inconsistencies caused by json_ext and complex structure of data model with multiple relations and columns.  

As the Individual model is defined, there should be no unnecessary null values, as all fields are defined as non-nullable (null=False). Querying and analyzing data as well as predicting behavior of structure in the system would be easier. 

The Individual model is simpler and thus easier to understand. Maintenance should also be easier due to the small number of fields and the flexibility provided by json_ext. There is a caveat regarding overusing the json_ext field to store various types of data with different structures. It may become difficult to understand which data is stored for each individual item and how to work with it.

Business Use 

Business requirements of Insuree model that are problematic from perspective of Social Protection: 

1. Insuree is required to have a relation with family in order to properly function in the existing system. Each Insuree can be added only to one family.(might be also confusing since not every individual added to the system should be considered as Insuree, if he/she will be added only for SP reasons)

2. Insuree require chfID for premiums and policies.

3. Gender and Age are required by core category masks.

4. FHIR API use Insuree chf identifier in multiple contexts.  

Family model has it’s own requirements regarding the location. Location structure is also strict and has an inflexible 4 level location hierarchy with parent-child relationships and users binded to district level. While it’s working for the current requirements, existing location logic may require rework in the future, new features created for core-mis purposes doesn’t have location restrictions, and therefore no changes are proposed for the time being. 

Based on that it would be hard to use existing Insuree as source for personal information without either: 

1. Ensuring that data required by claims and policies is provided

2. Adding proxy models that would dispatch Insuree data between different business contexts. It would be similar to use Individual model but with more data stored in different tables and increased modules coupling. 

Insuree module dependencies: 

1. Core 

2. Location 

3. Policy

   1. Medical

   2. Contribution

Individual is providing flexible information about a person, and has no real business use, except for being a core for all beneficiaries in the system (Insurees and Social Protection ones). Therefore the amount of stored information and dependencies are reduced to a minimum.  

Module dependencies: 

1. Core 

Current Data Structure Use in the System 

[LINK] 

[LINK]

Health Insurance

Social Protection

Data Collection and Data Requirements

Data Requirements for health insurance data is related to health and demographic data. Requirements for eligibility and claim categorization are known ahead and refer to gender, age, family relations, imis identifier (chfID).

Data requirements are known for single program and there are barely any common points. Data can refer to very specific like “Number of elderly or disabled dependents” or “Proximity to disaster-prone areas”. Sometimes those values are not even known from the survey and data might require transforming (like determining the number of disabled dependents is based on answers from each dependent in the household).

Financing and Risk management 

Can rely on pooled funding that might be a premium paid by insurees.

Also can rely on pooled funding. No premiums, might be public funding or donations. Note: financing is not part of the MVP, it is mentioned because there are similarities between Benefit Program definition and IMIS Product. 

Stakeholders Management 

Variety of stakeholders. These might include the individual participants, service providers, funding sources, and regulatory bodies. These depend on the implementation. 

Benefit Provision  

Benefits are provided when a specific event occurs - could be hospital visit, injury. Benefit is not paid directly to the individual, but to the service provider. 

Usually provided regularly not tied to events, provision is provided directly to the individual. 

Regulation and standardization 

Heavily regulated, good standards for handling of claims, data structures and processes. Global standards for data and requirements exist (FHIR, openHIE). Easier interoperability of systems. 

Subject to different regulations, might depend on the implementation and program. No acknowledged global standards are in place.