This document summarizes the openIMIS features provided by the Persons & Families module.

• it naturally references the current openIMIS documentation (the Web application user guide)

• … and the openIMIS functional design specifications (2017, referring to TZ version)

• it provides some refinements deduced from legacy code readings

• it lists taken hypothesis (whenever ambiguity or incomplete description was encountered) and attention points for the migration to the new openIMIS architecture

The module features are, among others, used within the scope of Beneficiary Enrollment business processes.

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 his registered health facilities.

Actors & Rights

Health Facilities staff

Receptionist:

• Search (and verifies) for patient data (in the scope of claim entering)

//note: does not have write permission!

Scheme administrator & district Staff

Clerck & Enrolment Officer:

• Search, create, modify and delete insurees and families

Accountant:

• Search for insurees and families (in the scope of contribution management)

//note: does not have write permission!

NOTE:

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

Other IT System (API calls)

• Enter insurees/families

• List (active) insurees/families

Family management Features

Find Family

Classical search/result panel page, with classical search criteria (family name,…).

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).

Family/Group Overview

The Family/Group Overview provides a summary of the family composition, the related policies and contributions. The latest two are part of the Policy module and Contribution modules, but is (will be) implemented in the scope of (as frontend contribution to) the Insurees & Families module.

Family/Group Overview mocks in Material-UI

Classic Layout - material sandbox link	Tabs layout material sandbox link

Classic Layout - material sandbox link	Tabs layout material sandbox link
Open Open	Open Open

Voting poll: https://doodle.com/poll/tfpu6xh7qs2kzk87

Will be added (feedback 27/05):

• Pagination in tables (as for claims)

• column sorting (as for claims)

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

Questions, remarks and warnings:

• In contribution section, straight link to Payer may not be possible (until Payer module is migrated)

Adding a Family

Simple menu entry to a ‘blank’ Family/Group Page (here under).

Note:

When creating a new Family/Group, user is required to provide the Family and Family Holder (who is an isuree) 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 make (via django migration) the FamilyID field in tblInsuree table optional. This will allow us to create the Insuree entity without any referenced 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).

Editing a Family/Group

Simple link from the “Find Family” page to pre-filled Family/Group Page (here under).

Note: Changing a Head of Family/Group and Moving an Insuree are 2 specific Family/Group edition features with dedicated UI (forms).

Family/Group Page

The Family/Group Page is dedicated to create/update a Family/Group.

Family/Group Page mock in Material-UI - material sandbox link

Open

Insuree management Features

Find Insuree

Classical search/result panel page, with classical search criteria (insuree name,…).

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

Adding an Insuree

Simple link to a ‘blank’ Insuree Page (here under).

Editing an Insuree

Simple link from Find Isuree result table to the Insuree Page (here under).

Insuree Page

Insuree form, small remarks:

• as for claim, user will only be able to select the region/district he’s registered in (as for claims)

• the photo will be upladed in a dedicated ‘storage’, which is by default, mounted to a standard file system (as for claim attachments)

Insuree Page mock in Material-UI - material sandbox link

Open

Deleting an Insuree

Simple delete (logical, by adding the validity_to date), with confirmation dialog.

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).

Operational reports/print-outs

Operational reports/print-outs are the necessary reports/print-out in ‘day to day’ management of Insuree & Families. The ‘BI’ reports (accessible via the Tools | Reports menu entry) are not part of this module.

There is no operational report/print-out in insuree & families module. There is a “beneficiary card” field at insuree level to depict wherever the insuree has a beneficiary card (or not), but the beneficiary card is not generated from the openIMIS application.

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 Policy module will be migrated, Policy (re-)valuation service will be ported from stored proc to python.