Digital Square D1 proposal: Support for Formal Sector schemes and Configurable Claims Workflow in openIMIS
Teams:
Objectives
This project aims to develop the "Formal Sector" features requested by institutions in charge of developing health financing schemes in Nepal, in particular the management of enrolment of the insuree as part of an insurance group.
Here are the high-level use cases to be covered by this design:
Manage group insurance
UC1 - The Scheme Administrator wants to manage the policy holder insurees and their policy entitlement. (includes UC2 from the proposal)
UC3 - The Scheme Administrator wants to manage the policy holder contract.
UC4 - The Scheme Administrator wants to manage the policy holder contract payment.
UC5 - The Scheme Administrator wants policy holders insuree policies covered by a contract to auto activate based on policy holders contract payment.
UC7 - The Scheme Administrator wants to manage policy holders.
Contribution Plan and Contribution Plans Bundle to manage the Policy Value
UC8 - The Scheme Administrator wants to add a Contribution plan (pricing rules linked to an insurance product).
UC9 - The Scheme Administrator wants to be able to configure the calculation parameters in the Contribution plan.
UC10 - The Scheme Administrator wants to add a Contribution Plan Bundle.
UC11 - The Scheme Administrator wants to enable some Contribution Plan Bundles per policy holder.
Policy holder Portal
UC12 - The policy holder wants to manage its policy holder insurees and their policy entitlement.
UC13 - Policy holder wants to manage its users.
UC14 - Policy holder wants to manage its contracts.
Not Functional
UC16 – Manage the calculations
Modules
The following module are part of the Formal Sector scheme management:
General topics (compitation accross modules)
Authorities
To manage the group insurance several authorities will be added, the existing authorities have a "*" :
PolicyHolder
C/R/U/D (4 authorities)
Portal R
PolicyHolderInsuree
C/R/U/D (4 authorities)
Approve (TBC)
Portal C/R/U/D (4 authorities)
PolicyHolderContract
C/R/U/D (4 authorities)
Submit
Approve/ask for change
Amend
Portal Submit
Portal Amend
PolicyHolderContractDetails
C/R/U/D (4 authorities)
Approve
Portal C/R/U/D (4 authorities)
PolicyHolderUser
C/R/U/D (4 authorities)
Portal C/R/U/D (4 authorities)
Payment
C*/R*/U*/D*(4 authorities)
Submit (TBC)
Validate
CreditNote
ContributionPlanBundle
C/R/U/D(4 authorities)
Portal R
ContributionPlan
C/R/U/D(4 authorities)
Portal R
Roles
To manage the group insurance several roles will be added, the existing roles have a "*" :
SchemeClerk(*TBC)
PolicyHolder
C/R/U
PolicyHolderInsuree
C/R/U/D
Approve (TBC)
PolicyHolderContract
C/R/U
Submit
Approve
ContributionPlanBundle
R
ContributionPlan
R
PolicyHolderContributionPlan
R
SchemeAdmin*PolicyHolderC/R/U/DPolicyHolderInsureeC/R/U/DApprove (TBC)PolicyHolderContractC/R/U/DSubmitApproveContributionPlanBundleC/R/U/DContributionPlanC/R/U/DPolicyHolderContributionPlanC/R/U/D
PolicyHolderClerk
PolicyHolderInsuree
C/R/U
PolicyHolderContract
R/U
Submit
ContributionPlanBundle
R
ContributionPlan
R
payment
submits
accountant*
Payment
Validate
Database Versioning
The entities will have different versioning in place:
Entity related to a specific date (contract …) no versioning will be in place only logging/audition, the code or reference will be used to differentiate them on a business level.
Configuration item (Product, plans, bundle, calculation, policy holder, policyholders insuree): those could be replaced by another version at a given time therefore no CI could have the same code and overlapping validity dates; they will have
DateValidFrom (date)
DateValidTo (date)
Active
Code (this stays the same across version)
Sub tables won't have any versioning because a new version of the parent table will create a new row in the sub tables.
Drop down list
The configuration of the the droip down list won’t be on the database but on the module configuration, in case a configuration is required across al module, the code will be updated to accept this configuration