Deletion

in openIMIS nothing is deleted to keep a good auditing level therefore when a user delete, he actually set a flag in the database raw, in order to see the deleted item a “show deleted” option will be available in the search, “isDeleted” flag will be added on the database Model

Nice to have a Undelete in place of the delete for deleted Item

Open

The material UI Delete might be used for the delete button

Open

The material UI RestoreFromTrashmight be used for the undelete button that could repalce the the delete button for deleted Item (nice to have)

Activation

For now few item could be deactivated, this will be true for calculation only, therefore “isActive” won’t be part of the standard model for now.

Material UI switch might be used

Auditing / History

The Django module django-simple-history will be use to keep track of all the changes done in the instance

A history journal should be available for a given instance, the format need to be defined.

UI Material Icon TrackChanges might be used

Replace/Edit

Replace and edit are two different actions, edit will update the instance meaning that this update will also impact the time before the edit, e.g. if a policyHolder insuree is edited to change its income, if a contract need to be generated in the past (still after PHnsuree DateValidFrom) this contract will take the edited income. But if the same PH insuree need to be replace by another version; this means that the former instance (fi) will have its dateValidTo set to dateValidFrom of the new instance(ni) (if fi.dateValidTo is null or greater than ni.dateValidFrom)

Material UI “redo“ might be used for replace

Material UI “edit“ might be used for edit

Wording (to be discussed):

• Replace is “Apply changes on a date, old value will be valid before that date”

  • Replace should be greyed out if the entity was already replaced

  • Replaced entity should not be updatable

  • When a replacement entity is deleted, the link should be removed from replaced entity so a new replacement could be generated

• Edit is “Apply changes, old value will be lost”

Date valid From-To filter Filter

The date filters (dateStart, DateEnd) should work in such way that all entities that were valid at some point in the filtered windows should appears:

• If dateStart is not specified it should be

  • Today if DateEnd is not specified

  • min (Today, DateEnd ) if DateEnd is specified

• Entity.DateValidFrom should be before the DateEnd if DateEnd is not null

• Entity.DateValidTo should be after date DateStart if Entity.DateValidTo is not null

Bulk actions on query

context: In real implementation there is not enough people to look at every claims, contract … meaning that most of those items are approved without a review (this was also the reason why claim AI module was developed). this means that the insurance worker will need to able to approve claims, contract … by bulk. Those bulk updates could targets hundred of thousand items, this means that we should avoid to send all the id back and forth between the front and the back end.

Solution proposed:

The bulk change could take the form of the normal mutation that support changes on an individual entity (claim, contract …), a list of entity or a Query

• the mutation will have a uuid field that will be used when there is only one entity

• the mutation will have a uuids field that will be used when there is a list of entities

• the mutation will have a query field that will be used when the entity need to be fetched with a query (Ideally same json payload as the graphQL querry )

uuid should have the priority on uuids that should have the priority on query

Then the mutation will create queryset based on the uuid/uuids/query

Then additional filter could be added to ensure the entity are eligible for the mutation

In case the query set return an empty result list then mutation should reply “not eligible <RessourceName> found“

The mutation itself should use the queryset in order call the database at the last moment.

if there is less than <confparamListSize> entities in the queryset, uuid of the entity will be returned with a appropriate status

if more than <confparamListSize> entities in the queryset, only the number of entity per status will be return (X errors, Y success)