...

The PAV Dashboard is intended to display data collection from the miscellany of sources described on this page. It's important to note that two of them, SELV and SISMA (DHIS-2), follow the MoH standard described here wherein reporting periods begin on the 20th, end on the 21st, and thereby span two Gregorian months. Every other report relevant to the PEV Dashboard uses the traditional calendar, wherein each period begins on the 1st of the month and ends on the last day of the same month. The original Excel-based version of the Dashboard reflects these differences. For example, users viewing "February" data which originates in SELV or DHIS-2 are shown information relevant to January 20th - February 21st. Meanwhile, users reviewing "February" data from a system like ColdTrace are presented information related to February 1st - February 28th. The new version of the Dashboard should behave the same way as the original version in this regard.

...

There was discussion at one point that the MoH wanted to define 1 "stockout" event within the SELV+ Dashboard as 5 consecutive days without stock. This is no longer the case. The SELV+ dashboard could therefore draw its stockout values directly from OpenLMIS if it were to report on them. Ultimately, however, because the Dashboard doesn't have to directly report stockout days, it doesn't  matter how they're defined. The dashboard only needs to show the percent of facilities which have incurred one or more stockouts (regardless of duration) during the past reporting period. A single day sans stock qualifies a facility to count toward this percentage.

The MoH would like the Dashboard to display the number of days which current stock levels are projected to last. The Vaccines_Needs_Formula_Stock Availability_Months_weeks_Days.xlsx spreadsheet illustrates how to calculate the projected stock amounts, and these calculations should be performed during the data-ingestion process. Note that the coefficients shown within the spreadsheet should be easily configurable rather than hardcoded.

Although we previously thought otherwise, there may be is value in preserving and presenting historical stockout projections. 
Open Question: Stockout projections are based on the current stock, and this data presumably comes from SELV. However, SELV's data is reported a month (and occasionally two) after the fact. It seems as though even our most current stockout-projections will therefore be a month or two old. Are such projections nevertheless useful and actionable?
It would be sufficient and appropriate to show the projected stockout values in months. (For example: stock is projected to run out in 0.5 months, or in 1.5 months.)

The data collected within the SELV form shown above is saved to the epi_use_line_items table. The following query is slow as-as, but may serve to illustrate the data we need:

...

Timoteo Chaluco (Unlicensed): As discussed early on, it may be wise to acclimate our users to the idea of having a UI somewhat different than the current one.Clay Crosby (Unlicensed)'s comments:

Thanks for providing the URL. It looks like we'll receive one URL per location per year. If so, we would need to have one iFrame per location per year. Depending upon the amount of locations, this could be quite extensive.

Would it be possible for NexLeaf to give us the raw data in some other way than via an API? Could they produce a monthly CSV extract? What data do they use to generate this chart?

FYI I've provided a screenshot of the Chart's configuration here:

Image Removed

Update from Martin:

We were looking through the past plots we've experimented with, and we found one like below. This seems closer to what you have now and is an option for you to use as well. It is easy for us to make small modifications (like parameters to remove the titles, adjust the height, etc).

...

https://coldtrace.org/plot/coldtrace/lloyd/Tete/20180101/20180201/data/

Hi Clay Crosby (Unlicensed). I gave NexLeaf some more thought while on the plane and agree that our tentative approach isn’t ideal. Although we can always ask NexLeaf to manually produce a CSV extract, I’m concerned that we would be:

1. A) Degrading the solution’s automation and thus value, and
2. B) Adding reliance on the ongoing effort of a team which may not be beholden long-term to VR, the MoH, of this project. (I may be totally off-base here. It seems the groups we’re asking to manually provide CSV files, though, are directly affiliated with the MoH and can thus reasonably be expected to deliver.)

A drawback of reliance on NexLeaf’s visualizations is that they’re definitely a departure (and really a subset) of what the current dashboard displays. I think we first need to establish whether that’s acceptable. If it is, we can then focus on implementation detail. Because we only have three provinces, it seems we’d need just 3 HTTP requests. That’s probably palatable. Reliance on NexLeaf's imagery precludes presentation of the full range of ColdTrace data displayed by the original version of the Dashboard. Dércio Duvane confirmed, however, that this approach is still preferable than one which requires manual data entry

Rather than pull the data from NexLeaf as needed and on demand, though, it seems that a better solution would likely be better to pull and save NexLeaf’s images to our local database filesystem as part of the daily ingestion process. The benefits would be:

1. Potentially less load on NexLeaf (three X requests per day at most, rather three X requests every time a user views a the dashboard).
2. A better user experience given that our users have limited bandwidth, and trading a local DB query for three HTTP requests would likely be more performantretrieving X local files is more performant than performing X HTTP requests.
3. Inoculation to a degree against NexLsaf’s NexLeaf system outages. Even if NexLeaf is down when a user views a dashboard, we'd still be able to present the previously polled data.

I realize this approach would be a more work than simply using an iFrame. If we indeed want to rely on NexLeaf’s imagery, though, I hope it’s one we can consider.
Reliance on NexLeaf's imagery precludes presentation of the full range of ColdTrace data displayed by the original version of the Dashboard. Dércio Duvane confirmed, however, that this approach is still preferable than one which requires manual data entryIn descending order of specificity, facilities belong to a Central Level -> Province -> District. A current proof of concept created for the new Dashboard shows provinces like Gaza and Niassa - which is sufficient. If NexLeaf provides the requisite images, though, it would be nice if the Dashboard could show District data as well. This, however, it isn't crucial. If need be, we can simply refer users to NexLeaf's website for additional detail.

Because NexLeaf's imagery isn't necessarily user-friendly, we should include a key/legend explaining it.

...

RED stands for "Reach Every District" and REC means "Reach Every Community." The RED/REC report is a CSV file which will be delivered via an email attachment. When it is, it will obviate all previous RED/REC data which has been submitted. In other words, the RED/REC attachments are complete and wholistic rather than cumulative.  . They're also unique in this way - every other CSV provided to the system will exclusively contain data for the most recent period.

Although referred to as RED/REC report, the data emailed to the Dashboard will exclusively contain Districts. For our purposes, we need not worry about "Community" data.

The dashboard should display the total number and rate of districts for which planning and implementation has occurred.

SMT

The SMT is a static Excel tool provided by the WHO for province level stock management. We can consider it an immutable data sources.

...