PC: December 19 2017

Software Development Update

• Roadmap: Living Product Roadmap
• Current sprint: Backlog Grooming Sprint 42 (local fulfillment, Admin screen - create a program)
• Upcoming sprint: Backlog Grooming Sprint 43 (local fulfillment, Admin screen - create processing periods)
• Release: 3.3 end of March
  

Overall updates and topics under discussion:

• Upcoming dates:
  
  • Feb (week of Feb 12th or 19th): demoing stock management and features supporting vaccines (CCE, F&E, local fulfillment, reporting) 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
• Ona has started to work on reporting. Showcases will be every two weeks an hour before this call. Showcases are recorded here.
• Aspirational roadmap: Still in progress 
• DELAYED: 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 Gill and Matt Berg has expressed interest.

NOTE: Sign up for Google Group email list so you can see feature requests and update before the meeting (and between meetings). OpenLMIS Product Committee Email List

Please include information on how the feature is globally applicable (Global vs. Project-Specific Features).

OLMIS-3793 - Getting issue details... STATUS  and  OLMIS-3796 - Getting issue details... STATUS

Reason: Need to reach out to users about planned system outages or other events. Would be useful to enable this form of communication.

Question: Are we sending notifications to personal phones? This could become a financial burden for the end user.

Right now there are not many communications to the user. Planned to be 5 communications per year.

Applicability to other countries: There are other costs to users that would support this.

Email seems like a preferred channel.

SMS functionality could be added later, but right now there is an immediate need to show these messages to the user.

Would these be predefined notifications? Would there be additional rules or filtering that would be required? Are these adhoc messages?

These messages would be adhoc. These would be push to all users.

Have you considered 3rd party tools and using an extract-transform-load process to build a list of emails/phone numbers?

Could in-app notifications replace the need for direct user notifications?

No, currently we are sending out a mass email to manually to all users. We want to ensure all users are notified in advance in case they don't open the OpenLMIS application.

Technical effort includes trade offs:

• Difficultly of setting up ETL
• Need for displaying message sending failure/read reciepts

RapidPro is a 3rd party tool that Ona recommends (and is a great tool 

NOTE: We reached the maximum amount of time allotted for this section, other tickets and discussion will continue on the OpenLMIS Product Committee Email List.

Alfred Mchau, Christine Lenihan, Ashraf, Chris Opit (Unlicensed) it would be great if you could join and weigh in as some of the options will impact the current workflow of requisitions.

When requisitions are submitted out of order, a validation error is caused in the current OpenLMIS stock management logic.

To fully fix the problem we need to choose a solution from section 1 and section 2.

See this document for explanation of sections.

Questions:

2C If the rejected requisition goes back to the authorized state, it is basically going back to the first approval. Therefore, if there was only one approval, then there wouldn't be a reject option anymore.

When a physical inventory is recorded as part of a requisition, what is the date recorded for the physical inventory? The last date of the period is used for the physical inventory date.

Is there a way to conditionally relax this validation?

Are we supporting best practices? How does this effect data quality? Requisitions is inherently a two-piece process, so there are delays in the system because of requested amounts. Different options have impacts on data quality.

Understanding the outlined impacts on data quality, and which options are a non-starter is the most important part of the process.

Ashraf offered to give insights from VIMS

From Josh Zamor

I’ll offer that the problem is being able to capture data (stock movements from the last mile) while maintaining a high level of quality data. In a previous life I encountered a similar problem with the U.S. National Park Service and the solution that I proposed there which worked well was to accept what users were entering into the system (with text guidance to help them do the right thing), and then provide the management team with daily/weekly/monthly reports which summarized what people entered. This let the management staff spot mistakes in a summary, and then work with the staff that entered in the data to correct it. The summary: guide users but let them enter in what they think is right, while providing tools to management staff so they can spot mistakes in summary sooner rather than later.

To the options presented, this might manifest in the committee choosing to relax validations, but prioritize some new reporting work aimed at management staff spotting errors. </JoshZamor>

Follow up will happen in product committee email list.

Nuran Idris (Unlicensed) and Alfred Mchau it would be great if you can make the meeting to weigh in and make sure we are reflecting your inputs.

See presentation for discussion of Options A & B

Option A would only have a limited number of columns, and there would be no configurability per program.

People approving requisitions would want to know more information that is shown in Option B.

This could show the stock on hand in the date when the requisition order was placed.

From Nuran Idris (Unlicensed)