...
- Performance
- Needs to be responsive handling thousands of products on a smartphone over 2g internet (likely).
- Needs to work well offline or with intermittent internet.
- For end-users, it would be better to work like an App (you download it and you always have an icon to open the app, regardless of whether you have internet) rather than working like a website. With our current offline website, it's not as smooth. Users need to open their web browser, type in the OpenLMIS URL, and hopefully they had all the elements cached and hopefully they were still logged in from last session.
- Needs to support layouts that will work across a variety of mobile devices that we expect to continue changing rapidly.
- Sustainable Maintenance
- Community/organizational tech stack knowledge: current OpenLMIS community is focused on Java and Angular v1, less so on Android and Mobile.
- Which platforms will be stable for 3-5+ years versus which are still cutting edge or will require frequent re-work?
- Which platforms will we be able to hire/employ developers to work on?
- One person often wears multiple hats (I manage my store room, and I submit quarterly Requisitions) and internet is scarce. When Product Lists / meta data change or a regularly scheduled update to the software occurs, we need to conserve their internet usage. EG, updating 2 apps because one product list changed, incurring 2 expensive downloads would be looked at unfavorably.
Add Value Uniquely / Avoid Duplicating Effort
There is some question around whether the development of a mobile facet of OpenLMIS would replicate functionality already available in the mobile sphere (ie. Dimagi's CommCare Supply, Logistimo, etc). These products, however visible and successful, are not optimized for routine LMIS data collection of the 100+ products that health facilities often manage. As such, we believe there is market demand for a mobile data collection tool targeted at routine data collection across multiple programs.
- Support Re-use
- There are a few pieces that, once developed, we don't want to have to develop again or support separately in multiple apps (this means community apps - e.g. if there is an Odoo app for stock management, we desire for them to leverage) (WIP):
- Support for GS1 EDI and EPCIS
- Supporting GS1 identifiers read through a camera (barcoding - GS128 and GS1 DataMatrix) (through use of onboard camera, not dedicated reader)
- OpenLMIS Product Model / Product Master - especially where the mobile app is interfacing with clinical or assistive re-supply workflows. e.g. understanding product use (shot in the arm through a CVX code) and product identification (GS1 UDI) as part of one workflow in dispensing. Or in assistive ordering knowing that these 5 identified products in stock mean that this 1 commodity type orderable should be re-ordered.
- There are a few pieces that, once developed, we don't want to have to develop again or support separately in multiple apps (this means community apps - e.g. if there is an Odoo app for stock management, we desire for them to leverage) (WIP):
...