Curent status
Management of the version
openIMIS use a type 2 database were a row is added when a record is changed; there is two reasons:
in openIMIS, the first record is valid for the date-time of entry. if a item (product/service/price list ) need to start before then the Validity
Auditing
This enable to see the historical record in order to see who made which changes
Manage multiple version of a record
For some tables the business logic will refer to version of a record valid at the time of claim submission
Management of the reference to versioned records
The reference use the rowid for the versioned Item which can ease the joining but complexify aggregations mostly for the Item that just need auditing.
Future status
Management of the version
With the modular architecture, mutation table were added into the picture, those table could easily answer the auditing needs but it is unlikely to be a suitable solution to manage the versioned record because recreating past record from the mutation will consume too much compute power.
Most of the Item that needs versioning might also need update without publishing a new version, on the other end new version validity date need to be configured by the users
List of table that needs versioning:
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)
Management of the reference to versionned records
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 |