Curent status
...
Benefit package: required to assess claim visit type limit, ceiling, deductible …
Benefit package Services: required for assess Child / Adult ceiling, Amount limits, limit exclusiosn and relative pricing
Benefit package Items: required for assess Child / Adult ceiling, Amount limits, limit exclusiosn and relative pricing
Medical Item: tblItems required to assess frequency and mask of service: Is it really needed ?
Medical Product: tblService required to assess frequency, service type and category and mask of service: Is it really needed ?
Medical Item Price List : needed to unsure the agreement update are taken in account for the right claims
Medical Item Price List Items details : tblPLItems
Medical Services Price List: needed to unsure the agreement update are taken in account for the right claims
Medical Service Price List Service details : tblPLService
Health facility (for price list, type of care and catchement)
Location:Villages (for population)
...
The strategy to reference to versionned Item should be discussed
Constraints
The solution should help the database persormance
either using different tables
either have field on which the valid row could be used to generate clustered index (Null value is not making it easy)
The solution should enable the search on valid and historical event (could)
1 live table, 1 log table
When a record is created, it is created in both table
When a record is modified, it is created in log table and modified in the live table
when a record is deleted, it is only on the live table
Strengths | Weaknesses |
|---|---|
when using the live table, the historical value won’t be an issue full llist available in the log table | 2 tables should be managed duplicate data can be dificult to find the active record at a given time (can use TOP + order date creation ASC but it works only 1 reesult) |
Opportunities | Treats |
cluster index on the UUID + version (creation date … ) for the log table schema could block the editing right of the log table database trigger might be used for duplication | the queries can point to the wrong one |
1 valid table, 1 old table
When a record is created, it is created in live table
When a record is modified, the old version is moved to the log table and modified the live table
when a record is deleted, it is moved on the live table
Strengths | Weaknesses |
|---|---|
when using the live table, the historical value won’t be an issue avoid data duplication | 2 tables should be managed UNION required to have the full list |
Opportunistes | Treats |
cluster index on the UUID + version (creation date … ) for the log table schema could block the editing right of the log table during the mode the “Validity to” can be added in the old table | record might be modified in the live data by modules without creating old record |
1 table with validity dates
When a record is created,
When a record is modified,
when a record is deleted,
Strengths | Weaknesses |
|---|---|
easy to find the record valid at a given date | big table difficult to manage clustered indexes |
Opportunistes | Treats |
1 table with active column
When a record is created,
When a record is modified,
when a record is deleted,
Strengths | Weaknesses |
|---|---|
big table | |
Opportunistes | Treats |
1 table with version increment
When a record is created,
When a record is modified,
when a record is deleted,
Strengths | Weaknesses |
|---|---|
big table | |
Opportunistes | Treats |