Versions Compared

Key

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

bThis This document summarizes the openIMIS features provided by the Policies module.

...

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

Business definition of the policy dates

Enrolment date: Date when the insuree takes the insurance (not to be mixed up with registration date, where a person gets its insuree number)

Start date: contract start date

Effective date: coverage start date

Expiry date: date of the coverage and contract.

in the default enrollment:

Expiry date = Start date + Product Duration

Effective date is calculated based on the last installment (policy fully paid)

Start date, is either the enrollment date or based on the product cycle if any defined

Access Rights

There is no straight link between a Policy and a Location. However, a Policy is linked to a Family, which in turn is attached to a location. Besides role-based feature access control (cf. Actors and Roles here below), all policy management actions (querying, entering, ...) are limited by user’s location(s) scope: users can only access/manage policies of families listed for his registered health facilities.

...

  • there are filters on the location… but a policy is not linked to a specific location. So we assume the location criteria are on policies' families (… which can be down to ‘village’).

  • when double clicking on a policy from the list, the legacy app opens the family overview (!), we’ll replace this by the default behavior (open the entity itself - in this case the policy, but add a ‘open family’ button in the rows to access the family overview from the policies (i.e. as we did for the insurees)

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

...

Then, the Windows Service takes these XML files and HTTP posts them to the SMS gateway, one by one. This is in fact the only time consuming task as the others are pretty quick to execute.

⚠️ There is no feedback from the SMS submission in the database ! The Windows Service only writes the response of the gateway into the Windows Event Log.

Many SMS gateways use asynchronous callbacks to notify delivery failures. We did not find any evidence of this being handled in the existing code.