Mobile Strategy - Key Objectives

Vision

1. The OpenLMIS vision is to support a core set of LMIS business processes to be accessible via a web or mobile/tablet interface
2. There is a reference mobile interface which can be deployed "as is" or customized to meet the specific needs of each country (we expect that many countries will need to customize to deploy, but this cost is significantly less than if they had to start from scratch)
3. OpenLMIS offers a robust set of APIs which enable a variety of mobile tools (CommCare Supply, ODK, OpenSRP, Medic Mobile, etc.) to interface with OpenLMIS. Countries/implementors can select the mobile application of their choice.
4. OpenLMIS supports supply chain management processes down to the facility level.
   
   

Reference Mobile Application - Requirements:

1. Can be quickly deployed "as is" without software development, including ability to be configured to match the business requirements of a country  (how achievable is this? need exploration)
2. Meta-data alignment
   1. Product Master (Commodity Types, Trade Items, GLN)
   2. Approved Products, Min and Max
   3. Facility list (FHIR Location with GLN)
   4. Stock Adjustment Reasons
   5. Stock origin and destination lists (facilities approved to be)
3. User login
   1. User Auth and RBAC (online to authenticate, RBAC cached.  No network needed until network connection shows credential to be unauthenticated)
4. Direct to digital stock management (Stock on Hand by Program):
   
   1. Physical Inventory (aka Stock Take), with losses and adjustment reasons
   2. Losses and Adjustments (wastage, consumption, etc)
   3. Issue Stock (stock out)
   4. Receive Stock (stock in)
   5. Receive Stock using a VVM
   6. Receive stock from a shipment (POD)
   7. Receive stock from a shipment (POD) using a SSCC barcode (code 128)
   8. Record losses and adjustments using a UDI barcode (data matrix)
   9. Issue stock (picked with UDI barcodes) and packed into a box where we print a SSCC barcode
5. Requesting new Stock
   1. Stock-based, periodic, Requisition (from Stock on Hand and a calculated stock qty)
   2. Regular periodic Requisition (leverage Stock-based physical inventory, support fields such as:  stock out days, # of new patients)
   3. Receiving ASN/Despatch advice of a shipment being processed.
   4. Requisition Authorize
   5. Requisition Approval
   6. Work with (interop tbd) Program Data capture application to visualize programmatic data capture requirement as part of regular period requisition
6. Fulfilling an Order
   1. Fulfill an Order (Pick, Pack, Ship)
   2. Print a SSCC barcode (code 128) for the shipment
7. For implementations wanting a tailored user experience (i.e. match current country paper forms), can be customized(?) by a software developer
8. Implementation branding/themeing (implementer may brand/theme app without development cycle - ie through app settings)
9. Stock recall
10. Stock instance fraud detection (through interop with service providers - Optel?)

MVP and Rough bucketing of epics:

Key Points for Consideration 

• 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.

Current Plans for Integration

• We have plans to integrate with OpenSRP to support vaccine tracking at the facility level. Visit OpenSRP and OpenLMIS Integration for details.

Evaluating Options