2019-01-08 Check-in
- Ben Leibert
- Felimone Amone Junior
Date
Attendees / Stakeholders
Notes
TLS Cert
Ben can try automating issuance of the SSL cert upon which the NexLeaf dashboard is reliant. He'll need to coordinate with Jason, though, about how best to do so without interfering with existing configuration. It's okay for Ben to reach out to Jason.
Scheduling
We plan to give senior stakeholders within VillageReach a demo of the system the week of January 21st. In addition to showing them the system, we'll seek guidance on how urgently we need to deploy it for real-world use. This, in turn, will inform whether or not we wait for the next release of Superset. The menu of options we have for a production release is to:
- Downgrade our current instance of Superset. Clay does't think we should seriously consider this option because Superset's database schema differs from one version to the next. There's thus significant unknown and therefore risk associated with attempting to downgrade our primary instance. We don't currently know whether we can import our charts into an earlier version of Superset.
Temporarily use a separate instance of Superset. We currently use v28, and the alternate instance could potentially be downgraded to v27 or upgraded to v29. Ben would have to associate all of our charts with a temporary dashboard, and it would take Ona about a day's additional work to setup the instance. (There's a high-degree of risk associated with attempting to import data into an earlier version of Superset and a moderate degree of risk trying to do the same with a newer version of the product.)
- Upgrade our current instance of SuperSet to the 29rc (release-candidate).
- Postpone the release until Superset v29 is available.
- Use the system as-is for now, and upgrade to v29 when it's released.
(Post meeting note: Clay mention that option 1 is ill advised. Because on Ona's experience with release candidates has been so bad, and because setting up an alternate instance of the system is only estimated at a day or two's work, option 3 seems to carry much more risk than it's worth. This leaves us with options 2, 4, and 5. Both subsets of option 2 have significant cons. From a technical perspective, options 4 or 5 are thus the most appealing.)
We should consider the following when presenting the options:
- If all goes well, upgrading a stable instance of the system to the latest version of Superset should take 1 - 2 days effort. Because it may take time to schedule Jason, though, we should expect 2 - 5 days between the request for an upgrade and its execution.
- Clay estimates that Ona will conclude the actionable work they have right by this coming Monday. (This, however, is dependent of VR giving them district-level population metrics, confirmation that we've identified all temporal coefficients, and guidance regarding how to handle apparently erroneous data which resides in DHIS-2.)
- Ben's remaining work.
Clay feels okay about demoing on the week of the 21st. His main concern is about data integrity (described below in the "Division by Zero" section.)
Ona's Current Work
Husnia is an intern working with Antonnate.
She has already updated Nifi such that it fetches district-level rather than facility-level data from DHIS-2. As a side benefit, this reduces the number of API calls we make to DHIS-2.
Her next step is to update the main materialized-view such that it works at the district-level, and she estimates that this will be finished by Monday. This requires that VR furnish district-level populations values, though, and confirmation that we've identified all temporal coefficients.)
Division by Zero
Background:
The utilization indicator aims to convey levels of wastage and is calculated approximately as follows:
(people_vaccinated) / (open_vials * 10)
If you open a lot of vials but vaccinate very few folks, you'll have high wastage.
The open_vials coefficient is also called used_vaccines. Additionally, our materialized view refers to is as vaccine_name_unused, but this is misleading.
Problem:
The open_vials value is sometimes zero within DHIS-2 even while people_vaccinated is greater than zero. This doesn't seem to make sense, and leads to division-by-zero errors on our end. It's unclear how we should deal with this apparently erroneous DHIS-2 data.
It's necessary to get guidance from Felimone Amone Junior or Timoteo Chaluco (Unlicensed) regarding this.
District Dashboard
The Mozambique team hasn't shown much interest in the District dashboard. Its value would primarily have been for district-level employees to see facility-level data. We've agreed as a group throughout the project's development stage, however, that presentation of facility-level granularity is beyond the scope of the dashboard. Meanwhile, we couldn't track down reliable facility-level population metrics and are revamping the main materialized-view to work at the district rather than facility level. For all of these reasons, it seems as though we need to and should remove the district-level dashboard. Ben will socialize the idea with with Mozambique team.
Action Items
- Ben Leibert will socialize removal of the district-level dashboard with the Mozambique team.
- Felimone Amone Junior will provide Clay with district-level population values.
- Felimone Amone Junior will provide Clay with the code that DHIS-2 uses to identify each district.
- Felimone Amone Junior will offer Clay and the team guidance regarding how to deal with apparently erroneous DHIS-2 data described in the "Division by Zero" section above (about which Clay elaborated via email on 12/21.)