Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

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

...

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:

...

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 are proposing to make (via django migration) the InsureeID field in tblFamilies optional. This will allow us to create the Family entity without any referenced Insuree… and once the Insuree created (with a mandatory FK to the Family), reference the Family holder (InsureeID) in the tblFamilies table.

Editing a Family/Group

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

...

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)

Deleting an Insuree

Simple delete, 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).

...

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.