Deduplicaiton is a very complex process, I don’t think we will have the time-budget to address it but we could make sure the schema will be addapted
context:
a person have often several reference, normally identification system manage the relationships between them. but openIMIS must be able to function in a stand alone mode and because its privilege API is FHIR, some support could be achieved by implementing properly the FHIR identifier
Proposed approach
Today Beneficiary’s fields type_of_id and passport should be replaced by a one-to-many relationship so a beneficiary could be identified by several ids.
The number of required ids for the enrollment will depends of the implementation
batch could be executed periodically to extends the id list with the help of other servers
Side benefit:
could start the prerequisites for the Offline usages
this is a proposed strategy to ensure that a workable product will be produced, the “listing“ module could be done in a second phase (depending of the available budget)
Process
listing management will stay on coreMIS legacy until the openIMIS stack can manage properly the benefits.
The benefit management then will have 2 possibles workflow
claim based benefits
payment plan based benefits
this will depends on the payment plans attached to the program/product
unrelated aspects:
Grievance module may (Should have?)
contribution to the data lake (Should have?)
event based payment , aka timesheet based (Nice have?)