Call Information
- 6:00AM PST - Seattle
- 9:00AM EST - New York, DC
- 5:00PM EAT - Tanzania
- 10:00PM GMT +8 - China
Webex Link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M299H1X42RL8F1ABXL3LOKN9TN-3O29&rnd=371900.06805
Meeting Number: 192 173 465
Host Key: 352864
Audio Connection: +1-415-655-0001
AGENDA:
| Item | Time | Lead |
|---|
Software Development Update Governance Meeting Update and Requests - Request for a functional requirements/documentation toolkit to be developed
- Request for implementors to publish feature roadmaps
- Request for a 'combined' feature roadmap across all implementors and 3.x
Next steps to address the requests. | 10 min | |
Requisition Template Let's review the requisition columns and confirm which are needed and what level of extension is truly needed. - Normalized Monthly consumption
- Key decision: do we keep "normalized monthly consumption" or shift to "adjusted consumption" ?
- AMC
- Do we keep at three months or make it configurable?
- Would a country use AMC if they are doing a quarterly reporting schedule?
- Maximum stock quantities
- Should we stick with the current calculation or put in an extension point for an implementor to change which variable is multiplied by max months stock?
| 15 min | |
Offline with Requisitions - Review goals and approach
- Offline first
- Offline screens/actions
- Error handling
| 15 min | Nick Reid (Deactivated) |
Not enough time, moving this to the next meeting. Following up on Stock Management Remaining open questions. | 15 min | Moved to next meeting |
| Reminder: Next meeting January 5th (not January 3rd) same time and webex link. | 5 min | Mary Jo Kochendorfer (Deactivated) |
ACTION ITEMS:
ATTENDANCE:
NOTES:
(MJ)
SD Update
- starting a small team at TW to do stock management
- Next call will have more of an update on SM
GDHF
- Micro services session given
- Most people on this call were there
Governance call update - PC responsibilities
- Asking for having a functional requirement case tool kit
- requirements in a consistent and decentralized way
- Brian will help Mary Jo with that
- Request for implementors to publish feature roadmaps
- Request for ‘combined’ feature roadmap across all implementors and 3.x
- MJ: What do people think / suggestions on how folks that are implementors are going to do this - ongoing conversation
- If anyone has experience with roadmaps, and wants to coordinate with MJ, let her know
- Ashram: as an implementor, we can capture various features from roadmap, still don’t know existing countries can upgrade to 3.x immediately - how should we ‘combine’ them?
- MJ: ‘combining’ would be the roadmaps, not the codebases - if using JIRA, etc., make these public - and then ‘combine’ these (???) - we are thinking about doing X, someone requested to use bar code scanner
- Ashraf and MJ will schedule an offline meeting to figure out how this combining will work - time TBD
Requisition template conversation
(Overall, the proposals presented by MJ were met without any dissent from the group. There is a follow up that Ashraf will do around looking into SOPs to better understand some of the calculation questions.)
- MJ: will show what currently exists, and then go into questions with PC and decide next steps
- MJ: specifically focusing on the dependency chart on requitision template wiki - red is system generated, blue are calculations, green are proposals that we should discuss, purple was what was created in eLMIS - at bottom, open questions and explanations on what happened with eLMIS and why these options were created - will talk through these.
- MJ: light yellow is user input - explains new patients / doses - important for when we get into calculations
- First question — what is # of new patients trying to capture?
- Ashraf: for HIV / Malaria, people want to track who are existing users for new patients in order to see the earlier people are continuing or whether new patients are also coming in
- MJ: question on that - you described two different things - current patients + new patients in certain period of time - with Monthly Normally Consumption, is it clear that # of new patients are being combined with consumption?
- Ashraf: we are getting into an area where I’m not comfortable without consulting the SOP manuals and seeing those calculations they use in printed form - I can take task to come back with those answers
- MJ: specifically, why is it being combined and if there is a standard for combining consumption + new patients that are coming in for the next month? When I look at formulas, we may want to suggest pulling out quantiy of new patients into its own variable, b/c standards of WHO don’t bring in this new patient - point is for max stock or reorder calculation - do you put new patient info into AMC, seems fuzzy on why you would do that, but system is including that right now, don’t see that in standards
- Brian: great call out - seems to be changing history - good to look into SOPs as Ashraf is saying
- Ashraf: I agree, it’s a bit unusual - in most cases, I see historical consumption, they want to take into account stock out days, but for new patients need to see which scenario is applicable here hence want to dig into first
- MJ: Need to figure this out as soon as possible, this is last fields for requisition template to get finalized - I’ll update this chart in wiki, but still need to validate this
- MJ: For now MNC, eLMIS needed to do modifications to take into account periods, so if we are building configurable periods into our own OpenLMIS product, why are we doing monthly consumption - so I am proposing that we shift formula for MNC so adjusted consumption is just accounting for stock out days but just doing for the periods, whether monthly or quarterly
- Ashraf: that makes sense - we also wrestled with this but due to time pressures went with current implementation (AMC) - there was an inconsistency there, so any opportunity we can do it the right way / convince people, we should do that.
- MJ: next proposal - name becomes ‘average consumption’ - average consumption over periods - if period is monthly, then it would monthly consumption - if 3 months put in or 6 or 12, etc. then it works for all
- MJ: change max stock attribute to be a multiplier, more generic, so folks not using monthly schedule they just know it’s a multiplier - looking at putting extension point around the P in calculation
- Ashraf: need to leave, double booked unfortunately
- MJ: anyone else joining from your team? important to have JSI in offline convo? Make sure your team is a part of conversation
- Ashraf and MJ to follow up later on stuff that Ashraf (JSI) misses
- Ashraf: other JSI folks more available post-holiday time (January onward)
- Kevin: for multiplier, any other purpose besides max stock?
- MJ: havent’ thought of any
- Kevin: be more explicit about being max stock rather than being generic as multiplier
- MJ: we can include instructions, good point that we want to be very clear on this - can call it max stock multiplier - thouroughly explain it so user knows impact on reorder calculation
- MJ: for pulling out new patients, might need a bit more thought on whether to include in calculations or keep on its own, use with malaria or ARV, would just be a reporting variable unless specifically put into max stock piece.
- Brian: main point is preventing stock outs - so yes, proposal seems to get better about this.
- Relevant links from Brian
- http://apps.who.int/medicinedocs/documents/s19597en/s19597en.pdf
- http://apps.who.int/medicinedocs/en/d/Js7919e/7.4.html#Js7919e.7.4
Offline requistions
MJ:
- want to talk this through to show people exactly what we are planning to do with this
- we are not doing transactions offline - i.e. not going to tackle offline approving of requistions or changing state of requisitions
- hopefully that Ashraf and others who listen to recording we all know what will be shipping with offline functionality
Nick:
- Will walk through thinking and implementing offline requisitions for 3.0, talk about methodology, and how process will work, and then a couple of patterns we’re going to follow, then open questions we’d like feedback on.
- Following offline first - when building an application, it works offline by default - take actions so that screens work when losing internet connectivity
- (going through Google Slides via link on wiki) Only talking about requisition screens that are grey - when user entering and editing data - when those are changes to a requistioin state they need to go online and sync their data - what would this look like: when user starts a requistion work folow, requisition screen lets user now that they are offline / changes are up to date, save button is no longer saved but sync button, when user goes offline all action buttons are disabled, reminder that as users make changes offline, reminder to sync requistions, only when they go back online can they change requisition state, when offline can view requisition on view requitision screen showing which requitions saved currently
- Demonstrating screen shots in wiki page on functionality
- Should requisitions automatically save? Or save button that only means “save offline”?
- Currently, when user comes back online they can sync
- Removing save button would avoid confusion on whether you are actually saving and whether you are saving on local machine vs. on OpenLMIS server.
- Brian: likes the 4th slide on Google Slides slides shown by Nick
- Nick: If a user pressing Save all the time, is that a learned behavior that we want to change or not
- Nick: larger conversation around conflict handling - out of scope for 3.0
- Kevin: (In Google Slides 4th slide) - what is ‘Remove offline copy’
- Nick: user should have a way to delete this data from their browser, even if not a whole lot of data necessarily at first, might become a lot - so when user clicks this button, the idea is that the data will be removed from the browser.
- Kevin: what is the difference b/w ‘remove offline copy’ and ‘delete’
- Nick: ‘remove offline copy’ removes from local machine; ‘delete’ removes from server
- Kevin: would never have both of those then?
- Nick: if you were online, you could also remove your offline copy, nothing blocking from you on that
- Kevin: Understand the journey to do that - wondering about the end users we work with understanding what removing an offline copy is - they might not understand difference b/w online and offline - other option would be to remove ‘remove offline copy’ totally, we are not talking about saving a significant amount of data even over 2 years
- MJ: Is the automatic saving okay from the PC group point of view? Or should it be user driven?
- Brian: I’m with the automatic with the feedback that it has been done
- Kevin: and with a flag on when it was last saved
- YES, we are doing automatic saving
- When offline, disable buttons or not having them there at all?
- Committee in consensus that we should show disabled buttons and non-navigable items to the users
- MJ: Should a user be able to log out while offline?
- Danni: yes they should be able to log out while offline to prevent other computer users from accessing openlmis and there’s reason to have an offline login mechanism for the browser - Nick: good idea and should consider doing that, although it’s technically not trivial - MJ: let’s make sure we look at timelines before deciding on that
- MJ: Christine will be most impacted by this, so can follow up with you about this - Christine will be leading implementation in Malawi from VR side so will be first impacted with this functionality
RECORDING
ADDITIONAL READING: