Objectives

• document the benefit in a generic way

• document the comsumption in a generic way

• Provide a mechanism to increase the performance to calculate the balance per insuree - currently full table scans. It will be used by both modular BE and REST API.

Solution

schema:

• benefit_provided

  • benefit_package_details_id

  • date_from

  • date_to(nullable)

  • status

  • qty

  • recipient

    • type: insuree / group / user …

    • id

• benefit_package_details

  • type

    • numberOf

    • amount

    • periodicity

  • benefit_definition(visit hospital … )

    • Type

      • product_item

      • product_service

      • cash

      • other limits (visits, hospitals … )

    • id

      • id of item/service

      • null for other limit

  • value

  • insuree (only for limits that are personnal)/individual

  • benefit package id (policy)

  • balance (actually approved)

  • provisional (submitted claim)

  • temporary (draft claim)

  • limits

CoreMIS

• benefit_package_details table (existing ?) and benefit_provided should be created

• list of benefit will come from benefit_provided

• “hardcoding“ or rework of Benefit package definition to create the benefit_package_details with the cash benefit

MVP

Initial update

• For all policy,

  • for all insuree covered by policy

    • get all claim details covered by policy (column in item and services)

    • update the common limits

    • update the individual limit

    • save limits for item and service that have limits (date or number , 2 limits if both)

    • save all cached enquiry

Schedule task to update

• For all claims updates since the last run

  • get all policy details covered by claims (column in item and services)

    • get all the member of the policy

      • update the common limits

      • update the individual limits

      • save all cached enquiry