This page summarizes the openIMIS features that were determined in the analysis and therefore tested for delivery for the Persons & Families module.

The module features are, among others, used within the scope of Beneficiary Enrollment business processes. However the testing is determined for the use of the module at hand, and not interactions between different modules. An overall cross-sectional testing will need to be done at the end of the migration process. Please note that because of this, some buttons are not functional in this version of the module as they would direct to the Policies or Contributions modules that have not yet been migrated. Their functionalities will be updated once the other modules are available. 

Access rights

An insuree/family is attached to a health facility (as First Service Point). Besides role-based feature access control (cf. Actors and Roles here below), all insuree/family management actions (querying, entering, ...) are limited by user’s location(s) scope: users can only access/manage insurees/families listed for their registered health facilities. 

For the testing process, each page is tested through three scenarios in relation to the user roles:

• No access: for roles that are not allowed to view insuree and family information 

• Read-only: for roles that have access to the data but cannot add, modify or delete it

• Read and write: for roles that have access to the data, and are allowed to add, modify or delete it

Open

Though pages are available to all, access to the data is restricted.

Here below are described the various access rights that have been set up and tested. Each page has been tested for the various access scenarios described above (no access, read-only, and read and write). 

The testing here-described covers the Insuree and Policy module, and more specifically the Add Family/Group, Families/Groups and Insurees pages. 

The test is limited to the features, filters and fields migrated from the legacy and mentioned in the analysis.

Actors & Rights

Health Facilities staff

Receptionist

As a receptionist I want to be able to search and view insuree data (in the scope of claim entering). I cannot modify, add or delete information to the insuree or family. My access to insuree data is read-only. 

Role will be validated if 

• Receptionist role exists

• Receptionist can search for insuree and family data through the fields and filters provided

• Receptionist does not have write permission 

Scheme administrator & district Staff

Clerk & Enrolment Officer

As a clerk or enrolment officer, I want to be able to search, create, modify and delete insurees and families. My access to insuree data is read and write. 

Role will be validated if 

• Clerk & Enrolment Officer roles exists

• Clerk & Enrolment Officer can search, create, modify and delete insurees and families

Accountant

As an accountant I want to be able to search for insurees and families (in the scope of contribution management). My access to insuree data is read-only. 

Role will be validated if 

• Accountant role exists

• Accountant can search insurees and families

• Accountant does not have write permission 

Other roles

The other roles (Claim Administrator, Claim Contributor,…) are NOT allowed to search and therefore see the details of insurees and families.

Manager, Medical Officer, Scheme Administrator, IMIS Administrator

Other IT System (API calls)

• Enter insurees/families

• List (active) insurees/families

The API calls are either authenticated as an actual user and submitted to the same rules as tested in the user interface or with extensive authorizations and therefore cannot be tested here. The API authorization tests are included in the code of the application where suitable.

Insuree and Policies

Add a Family

Open

 Note:

When creating a new Family/Group, user is required to provide the Family and Family Holder (who is an insuree) at the same time. In the database schema, there are 2 ‘opposite’ foreign keys: one from tblFamilies to tblInsuree and one from tblInsuree to tblFamilies. Since FK fields are ‘not null’ on both sides, the only way to add records in these tables (from django model) is to continuously activate/deactivate the FKs. 

In order to prevent this, we will made (via django migration) the FamilyID field in tblInsuree table optional. This allows us to create the Insuree entity without any reference to a Family… and once the Family created (with a mandatory FK to an Insuree for the family holder), reference the  Family it belongs to (FamilyID).

As a user with no access or read-only, Add a Family options are impossible at all times.

As a user with a read and write role, in the Add a Family page I want to be able to 

• Add a new family from scratch 

• Add a new family by importing an existing Insuree as Family Head

Fields available for creation of new families are the same as legacy. 

TEST:

Families/Groups 

Note about the ‘historical’ checkbox:

The search in ‘historical’ values makes the assumption that archiving is performed “in live table”. This mechanism is under review (for performance reasons). This criteria may not be available anymore (depending on the new archiving mechanism chosen). 

As a user with no access, search results stay null at all times.

As a user with a read-only or read and write role, in the Families/Groups page I want to be able to search for Families or groups using the search criteria available. 

Search criteria

• All search criteria from legacy are available, and families can now also be searched based on head of family or family member

• Results are filtered as information is added to the search criteria

• Removing a search criteria automatically refreshes the results with the remaining selected criteria

• Location criteria are decision-tree based, so if a superior criteria is removed the lower ones are removed as well

• Criteria can be typed in if choice is more than 10 results. If there are 10 or less results a drop-down list is available

• Search criteria are kept in the form when switching to a different page

• A refresh button is available to remove all search criteria selected

Results

• Pagination of results to avoid scrolling 

• Column sorting is available 

Family page

• Payment summary list contribution (on top of or as replacement of contributions)

TEST:

Family Details

As a user with no access, I cannot view Family details.

As a user with a read-only or read and write role, in the Family details page I want to be able to:

• See the Family information as in Legacy

• See members, and access member details

• Select head of family amongst the Family members

• View policies Family subscribed 

  • View only last active policy or last expired policy

• View contributions of Family

• View payments of Family

TEST:

Insurees

Note: same remark as in Find Family about the ‘historical’ checkbox - it relies on current archiving mechanism (which is under review)

As a user with no access, search results stay null at all times.

As a user with a read-only or read and write role, in the Insurees page I want to be able to search for Insurees using the search criteria available. 

TEST:

Add Insuree

As a user with no access, search results stay null at all times.

As a user with a read-only or read and write role, in the Add Insurees page I want to be able to create a new insuree, or add a new insuree to a family. 

There are two ways to add an insuree. 

The insuree is created and then linked to a family - on insuree page click on the Create new insuree button to create an insuree. 

The family is selected and the insuree is added to the family - on family page at top of members list click on

• Add (move) existing insuree into family

• Create new insuree in family

 TEST:

Batch processing

Today nested in Policy renewal batch processing, there is a batch to identify insurees for which the photo is missing/outdated. This batch will be (technically) split from the policy renewal (sys admins will be able to schedule it in the same time frame but it will be a separate job).

Out of scope

When modifying the family composition, the Policy valuation must be updated.

Policy (re-)valuation is part of the Policy module. This module will call Policy module service, which will, in a first step, use the legacy business logic (uspAddInsureePolicy,…). When the Policy module will be migrated, Policy (re-)valuation service will be ported from stored proc to python.