2019-12-17 Requirements Review
- Ben Leibert
- Felimone Amone Junior
Date
Dec 17, 2019
Participants / Stakeholders
@Felimone Amone Junior
@Matthew Kumbuyo (Deactivated)
@Chongsun Ahn (Unlicensed)
@Christine Lenihan
@Ben Leibert
@Sebastian Brudziński
@Aleksandra Ciesińska
@Mateusz Kwiatkowski
Notes
Background and Question:
SELV allows for a catchment population value to be associated with both facilities and geographic zones. Because it uses a facility’s catchment population to calculate the facilities ISA, it needs to associate a target population directly with each facility.
OpenLMIS v3, however, allows administrators to directly upload ISA values. As such it, it currently has no need nor support for associating catchment-population values with facilities. Instead, it exclusively allows catchment-populations to be specified for geographic zones. Will that suffice? There was brief mention of a need for facility-level catchment-population values as well, but what would be the use-case?
Answer:
Although we won’t necessarily use facility-level catchment populations as coefficients within calculations done in OpenLMIS, having the values will likely be useful for reporting. We should therefore support them.
Question:
The requirements document includes the following.
5.3 FR-5: Stock Management
# | Title | User Story |
11 | Adjust stock movement | As a District EPI Manager, I need to be able to reverse and/or edit a stock movement, so that I can make sure I am keeping accurate data on my stock on hand; however, this ability needs to be limited to the most recent adjustment to prevent errors affecting stock on hand. |
By design, OpenLMIS doesn’t allow users to “reverse and/or edit a stock movement,” and instead supports stock adjustments. Is that alright?
Answer:
Yes, we can rely on OpenLMIS' in-built support for stock-adjustments.
Questions:
OpenLMIS' batch approval page looks like this:
Meanwhile, the following mockup had been suggested for Mozambique’s equivalent:
Is it important that the orientation be changed as shown? In other words, is it important in Mozambique’s version that rows are facility rather than product oriented?
How many facilities and products will the page likely need to support?
Should Mozambique’s version show costs, as is currently done in v3 of OpenLMIS?
Answers
If we customize OpenLMIS' Batch Approval page, it would be preferable to display values as shown in the mockup (transposing the position of facilities and products) because:
A) We’ll only have the products currently used in SELV – about 12 total. By contrast, we’ll have many more facilities. Being able to minimize horizontal scrolling in favor of vertical scrolling would likely yield a better UX.
B) The page will be used exclusively by provincial users whom wish to see aggregated district values. Grouping the page by district, as shown in the mockup, is thus important. (Although we could group by district even while using the page’s original orientation, it would take work and wouldn’t likely look as clean.)
Note that, in the mockups, the “<“ symbol is intended to show that the rows should be collapsible. In other words, users should be able to toggle whether or not the facilities associated with a given district are shown. @Sebastian Brudziński built on this idea: in order to minimize the amount of data shown on the page, we could have it exclusively show district-level data. Users whom want to drill into and/or modify the underlying facilities’ data could then click on the district, be taken to a page dedicated to its facilities, make changes on this second page, and navigate back to the parent (district-level) page afterward. Given the number of facilities we’ll need to support, this approach would likely be necessary if we opt to use the batch approval page.
Provinces typically have 8 - 10 districts, some of which have as few as 8 - 10 facilities. Maputo and Nampula districts, though, have around 250 facilities. There’s no way the current version of the batch approval page can elegantly support districts like Maputo and Nampula. Its current iteration lets users select no more than a page of 10 requisitions at a time. Even without this limitation, it’s unlikely that the page would simultaneously support anywhere near 250 facilities with any semblance of performance. Redesigning the page as previously described would be necessary.
As long as we would need such significant redesigns, we should consider implementing aggregate rather than batch approvals. They may be closer to what Mozambique ultimately wants. @Ben Leibert will find and forward a discussion the Core team had about several various options. @Chongsun Ahn (Unlicensed) will then consider the likely level of effort our various options would entail.
3. @Felimone Amone Junior will get back to us tomorrow regarding whether the page should display costs. SELV doesn’t currently do so, and their workflows thus don’t call for it. There was recently a suggestion that we show costs, though, and Felimone will look into it.
Question:
Would implementing these CCE Storage mockups suffice to meet the needs of our CCE Storage reports?
Answer:
It seems so, but @Felimone Amone Junior will review the mockups in more detail and let us know.