Last Meeting Notes: October 10 2017
AGENDA
Item | Lead (Time) | Notes | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Software Development Update
Overall updates and topics under discussion:
| 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:
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:
Comments?
Mobile Strategy
| ||||||||||
Emergency Requisitions
| 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:
| ||||||||||||
Upcoming UI Changes
| Can see here for changes for 3.2.1 | |||||||||||
| 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:
| GHSC: Tenly Snow (Deactivated) will attend. The OpenLMIS community has two panels.
|
ACTION ITEMS:
- Mary Jo Kochendorfer (Deactivated) Schedule a product committee call to discuss the tools used for tracking tests on OpenLMIS
- Mary Jo Kochendorfer (Deactivated): Schedule time for PC to define what metrics we want to see, and this will support the team in prioritizing what to focus on next for performance testing.
ATTENDANCE:
RECORDING:
Video: OpenLMIS Product Committee Meeting-20171024 1558-1.arf (download the WebEx video player here)
ADDITIONAL READING:
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.