Design Considerations

OpenLMIS

• Each facility in OpenLMIS should be a member of a requisition group in order to support the replenishment process.

• Admin should follow the upload sequence for intial system bootstraping defined at https://github.com/OpenLMIS/open-lmis/wiki/Uploads.

• All User workflows in OpenLMIS are governed by the Roles and Rights assigned by the admin.

• Requisition Lifecycle in OpenLMIS is defined as per Tanzania & Zambia Ministry of Health.

• Products replenishment cycle is based on the Program and Schedules, defined by Sys Admin.

• OpenLMIS does not track the delivery location of the requisition order in the current implementation.

• Once initiated, Requisition cannot be deleted as per current specifications.

Commtrack

• For CommTrack, AgentCode in Requisitoin APIs is for CHW submitting the Report. For other general use AgentCode represents any external user integrating with OpenLMIS.

• For CommTrack, each CHW operates under a parent facility.

• In OpenLMIS CHW are modelled as Virtual facilities.

• A single instance of OpenLMIS cannot support multiple CommTrack instances.

• OpenLMIS is a system of reference for Program products and parent facilities.

• CommTrack will use Atom feeds history for bootstrapping initial deployment data.

• All API requisitions will be tagged to the current period in OpenLMIS.

• OpenLMIS at the moment do not support requisitions request for past and future periods.

• OpenLMIS APIs do not support Emergency Requisitions. All requisitions created via APIs are tagged as Regular Requisitions in OpenLMIS.

• CommTrack_User needs to be assigned corresponding rights permission to call any OpenLMIS APIs. As a guideline to sys admins, these rights need to be given to the users via application admin section.

• CommTrack is expected to retain the RequisitionID generated for each Report submitted to OpenLMIS.

• OpenLMIS has basic requirements regarding the values to support the reorder calculations. The master template for individual Programs can be configured with combinations to suit various operating scenarios, provided each template configuration properly supports the reorder calculations. For the CommTrack integration, Stock On Hand is sufficient to trigger the requisition calculations.

• Create requisition API can be used for non-virtual facilities as per the defined master template configuration and user rights permission. APIs cannot be used for approving an R&R created for a non-virtual facility.

• Requisitions created via API will follow the regular approval hierarchies as per the requisition group setup for its parent facility + program.

• Requisitions need to be manually converted to order by an OpenLMIS user having convert to order right on corresponding warehouse as no existing API supports order conversation.

• OpenLMIS will throw an error for any unrecognised/undefined fields in API.

• All Atom feeds do not perform any User Authentication as per design.

vrMIS

• vrMIS is a Push based replenishment process.

• Offline collection of Data by field coordinators is supported and can be synced to the server only when Online.

• Facility supporting push based replenishment process should be a member of a delivery zone for the corresponding programs.

• Data setup for push based process also follows a specific sequence as defined at https://github.com/OpenLMIS/open-lmis/wiki/Uploads.

• There is no restriction based on periods while initiating a distribution or trip.

• Multiple users can initiate a same distribution.

• Cuurently all vrMIS screens are Non-responsive.