PC: October 24 2017

Call Information

  • 09:00 PDT - Seattle
  • 12:00 EDT - New York, DC
  • 18:00 CAT - Zambia
  • 19:00 EAT - Tanzania

  • Webex Link: LINK
  • Meeting Number198 977 185
  • Host Key626254
  • Audio Connection +1-415-655-0001 

Last Meeting NotesOctober 10 2017



Lead (Time)


Software Development Update

Overall updates and topics under discussion:

  • 3.2.1 Release candidate - aiming for  with a week long review period.  For details on our release process, please check out http://docs.openlmis.org/en/latest/conventions/versioningReleasing.html. We also have a detailed test plan for the candidate: 3.2.1 Regression Test Plan
  • Short-term Roadmap:
    • Dec: Proof of concept integration between DHIS2, OpenSRP and OpenLMIS
    • Jan: demoing stock management and features supporting vaccines (CCE, F&E, local fulfillment) to GAVI, Global Fund and others to spark interest in using OpenLMIS to manage vaccines.
    • March: release 3.3 with the minimal set of features to support managing vaccines sub-nationally
  • Aspirational roadmap meeting happening with PATH later today () Given the two examples below, what thoughts feedback do you have for the OpenLMIS community. Do you think one of these approaches serves our community better than on the other? 
    • Examples of other open source roadmaps: 
      • OpenNebula: Roadmap. Ticket based input and coordination. Members can suggest features and then they are slotted for work based on specific criteria. View of features
      • OpenStack: RoadmapOpenStack is committed to an open design and development process. The community operates around a six-month, time-based release cycle with frequent development milestones. During each release cycle, the community gathers for the Forum to gather requirements from users, then developers meet at the Project Teams Gathering (PTG) to begin development work and cross-project collaboration. Example community generated PDF roadmap, here.
  • Defining our mobile strategy. Are members willing to meet separately to help define the OpenLMIS vision for mobile applications? Put on your OpenLMIS hat (not your country hat or org hat) and outline the critical needs for OpenLMIS.
    • Currently we are working towards one new reference implementation with OpenSRP for the 3.3 release.  The details of the reference implementation are outlined here: OpenSRP and OpenLMIS Integration
    • Parambir has expressed interest.

Mary Jo Kochendorfer (Deactivated) (15 minutes)

Updates from Mary Jo: New release candidate process.  Documentation about release process is on our docs.openlmis.org. Each release will have clearly documented roles and responsibilities, full regression, etc.  JSI and community helping with the testing, bugs.  A lot of details - release candidate for Wednesday for final release 3.2.1.

Upcoming deadlines:

  • December - GDHF: hosting a Lab doing proof of concept integration b/w DHIS 2 and OpenLMIS.  Also bringing in OpenSRP
  • January - Demo Vaccine feature set
  • March - 3.3 release

Aspirational roadmap - two approaches we are exploring

Call scheduled today with PATH.  Two examples of communities to discuss - how to define our long term roadmap:

  • OpenNebula - don't see high level roadmap but see specific features for upcoming releases
  • OpenStack - more hands one approach.  Specific meetings with the community. Very hands-on, participatory to defining the roadmap.  Must be in person.


  • OpenStack may be hard since we are dispersed over the globe.  
  • Could do a hybrid approach - use Nebula ticket based system and then have discussions and gather using participatory approach in OpenStack.  
  • To formalize the process, may need to define a change review process - how will we as a community manage changes?  Also need to clarify how members make key decisions for long term projects.  What will the future look like? 

Mobile Strategy

  • We will move forward with a reference implementation for vaccine work.
  • Pieces around mobile integration was included in gap analysis.  
  • We will continue to review other experiences - conversation is still ongoing.  Let Mary Jo know if you have interest in this side conversation.

Emergency Requisitions

  • Current validations and requirements 
  • Gap analysis scope
  • Ideas going forward
Sam Im (Deactivated) and Mary Jo Kochendorfer (Deactivated)

Malawi has requested improvements in how Emergency requisitions are handled.

They currently look and feel like a full requisition.  Sam did research on needs in TZ and has also talked to the Malawi team.

Sam met with Noran and Alfred.  Problems are tied to creating emergency requisition and creating it in a way that is efficient and doesn't require a user to require ALL requisition form fields.  When you submit emergency requisition its a report for all products.  Sam met with Nick and came up with some short term options. Data integrity is not ideal for quick fixes.  These are not long term solutions - more work around.  

Long term - Do we think we'll continue using emergency requisitions as they have been designed?  Should we redesign and prepare for a longer term solution?  Do we wait to review since this was in gap analysis?  How do we better understand priority for long term solution?

Emergency requisition is based on the country logistics systems.  Some countries not using this feature.  We need to review and discuss this further because as countries move to electronic systems the process will change.  The way it is done using paper will change as they move to digital systems.  for example, you don't need to load the entire R&R when users load request.  Maybe we need to think about a new approach, new process flow - not base this on the old approach.

In Zambia - similar sentiments.  Users want to do an emergency request for a few products but don't want to do a full top up of all products.  Observation is that while this makes work simpler for the users, you'll see facilities go to the central medical stores up to 3 times per month for more supply.  Interferes with medical stores capacity to process regular orders b/c emergency orders take precedence.  A lot of work load to meet demand for emergency orders - this pushes regular orders significantly.  This is valid in Malawi too since they operate on a monthly system.  

In Malawi there is an online ordering system operated by central medical stores.  That has been going on for at least a year - working well.  They want this implemented in OpenLMIS.  There has been a working model already and what we are proposing with OpenLMIS is less than this - a challenge in Malawi.  In OpenLMIS, majority orders on essential meds.  Order form is about 14 pages.  For main hospitals, they care about ordering 3/4 of items on OpenLMIS form.  Many balances zeroed out so they can move forward - Creating a data validation error.  Would prefer another approach for emergency orders.

Perhaps take a step back - what do we think is the ideal state in Malawi and what systems support this?  Ensure there is flexibility in configuration in the process to meet needs of the country. Big gap between Ideal State and current processes.

Emergency orders are indication that system isn't performing well.  Supply chain manager at the facility need to address the issue.

Mary Jo - we may need to put together some ideas and proposals to address this important issue.  Maybe have another meeting to talk specifically about this.

Read out from In-Person Meetings: DHIS2, OpenLMIS, OpenSRP

Request for action: please insert comments or flag areas of concern directly in the notes. Please @mention me.

Mary Jo Kochendorfer (Deactivated)

Several meetings last week.  Key findings and next steps.

We are moving forward with OpenSRP/OpenLMIS reference implementation to demonstrate end to end data capture for vaccine functionality. Want to track stock movements, wastage levels etc - receive incoming shipment information and notify facilities when orders are fulfilled and on the way. Idea is to push info from OpenSRP to OpenLMIS to make decisions about stock to facilities.  See notes in link.  Notes still in draft.

Digital Health Forum - always has been a request in integration for DHIS 2.  Focusing on Vaccine and DVDTM report for WHO.  Want to demonstrate a proof of concept of how two systems can push data into DHIS 2 and see the reports in DHIS 2.  Think about where data is best collected and visualized for taking on needs from central level.

Reach out to Mary Jo if you have questions/input.

Upcoming pull request:  OLMIS-3233 - Getting issue details... STATUS

Upcoming UI Changes

  • OLMIS-2700 - Getting issue details... STATUS
    • Removing columns "Date Authorized" and "Date Approved" from the view requisitions page
    • Implementing sort order: Default sort order is by Date Initiated

Can see here for changes for 3.2.1

OLMIS-3254 - Getting issue details... STATUS  unrestricting information to improve performance and cache. It will require a login. We understand price could be sensitive and as we look to enhance how we manage product prices we can look to create a new endpoint to restrict further.

For improving user experience load time - what information is sensitive?  There is a log in but not specific for the role.  Price information?  If price schedules are in gap analysis, then make an end point around prices to pull them out for caching updates.

Upcoming conferences:

  • TechNet in Portugal (Oct) - PAST

  • 10th Global Health Supply Chain Summit, Dates: Nov 15-17 (Accra)
  • Global Digital Health Form in DC (Dec)

GHSC: Tenly Snow (Deactivated) will attend. The OpenLMIS community has two panels. 

  • HMIS - LMIS integration
  • OpenLMIS vaccine featureset




Video: OpenLMIS Product Committee Meeting-20171024 1558-1.arf (download the WebEx video player here)


Long-term Roadmap

Thoughts? What's missing? 

  • Some of the items are overlapping but trying to find a way to demonstrate the longer term goals within features, performance, standards and integrations.  

OpenLMIS: the global initiative for powerful LMIS software