Hi devs,
having spent quite a bit of time in recent months defining output and dashboards, I’ve come across a few gaps that I’d like to highlight.
The first is an issue I also wrote about on the list some time back, which relates to relative periods and "cumulative aggregation" (not sure how to phrase it).Programmes that track progress throughout the year (often with targets), for example EPI, use "months this year" displayed cumulatively as the main way to track progress. By "cumulatively", I mean that the value for march (whether it is an indicator or data element) would be jan + feb + march, april would be jan + feb + march + april etc.
The second issue is support for some additional relative orgunits, and the posibility to combine fixed and relative orgunits (as can be done with periods). For relative orgunits, it would be very useful to have "parent orgunit", and "peer orgunits" to include orgunits with the same parent as the user orgunit. Both allow you to have reusable output that can be used to show performance etc relative to related orgunits. That is also the reason I think it would be useful to be able to combine fixed and relative orgunits, so that you could for example have a favorite showing the indicator for your orgunit with the national value.
Are these things something that could be considered? Would be happy to write blueprint(s).
having spent quite a bit of time in recent months defining output and dashboards, I’ve come across a few gaps that I’d like to highlight.
The first is an issue I also wrote about on the list some time back, which relates to relative periods and “cumulative aggregation” (not sure how to phrase it).Programmes that track progress throughout the year (often with targets), for example EPI, use “months this year” displayed cumulatively as the main way to track progress. By “cumulatively”, I mean that the value for march (whether it is an indicator or data element) would be jan + feb + march, april would be jan + feb + march + april etc.
okay so what you mean is that data should always be cumulative within the year? Meaning it is sort of a “so far this year” report? This is a bit more specific compared to general cumulative function, where one could imagine having cumulative values across relative periods (e.g. last 12 months).
The second issue is support for some additional relative orgunits, and the posibility to combine fixed and relative orgunits (as can be done with periods). For relative orgunits, it would be very useful to have “parent orgunit”, and “peer orgunits” to include orgunits with the same parent as the user orgunit. Both allow you to have reusable output that can be used to show performance etc relative to related orgunits.
This becomes a bit of a conflict with the “data view org unit” solution. As you know, for users we define one or more “data view” org units, which will define the root of the org unit tree in analysis apps. Often there is a security aspect to this, in the sense that you do not want to allow people to see org units outside that boundary/root. So by allowing for peer/parent data view org units one will violate that principle. Of course we could have Yet Another Setting for this but that is getting more complicated than most people appreciate. I suggest that you simply set the data view org unit for users one level higher up in the hierarchy to achieve this.
That is also the reason I think it would be useful to be able to combine fixed and relative orgunits, so that you could for example have a favorite showing the indicator for your orgunit with the national value.
This we can do. In fact combining relative and fixed org units is already supported in the API so it will be a UI feature. Blueprint:
Yes, it’s like a “so far this year” report, but by month (or other type) rather than just the total so far this year. The generic solution might be to add the two things separately:
“months (etc) this year” as relative period, which I think would be useful in it’s own right
a general cumulative function that works across whatever period is selected
My thinking in cases where you don’t have access to see peer/parent, or they don’t exist, they would just not be included - similar to the “subunit” orgunit today in cases where the user orgunit doesn’t have any subunits.
Also, if I’m not mistaken, the relative orgunits use the data entry/maintenance orgunit rather than the data view orgunit, so assigning a user to the “parent” in the data view hierarchy wouldn’t change anything in terms of the relative orgunits.
What we want to achieve is that a users in a district can have a favourite/dashboard with his/her district together with the other districts in the same province/region (peers), or that a facility can have a favourite/dashboard with his/her facility vs the overall district data.
having spent quite a bit of time in recent months defining output and dashboards, I’ve come across a few gaps that I’d like to highlight.
The first is an issue I also wrote about on the list some time back, which relates to relative periods and “cumulative aggregation” (not sure how to phrase it).Programmes that track progress throughout the year (often with targets), for example EPI, use “months this year” displayed cumulatively as the main way to track progress. By “cumulatively”, I mean that the value for march (whether it is an indicator or data element) would be jan + feb + march, april would be jan + feb + march + april etc.
okay so what you mean is that data should always be cumulative within the year? Meaning it is sort of a “so far this year” report? This is a bit more specific compared to general cumulative function, where one could imagine having cumulative values across relative periods (e.g. last 12 months).
The second issue is support for some additional relative orgunits, and the posibility to combine fixed and relative orgunits (as can be done with periods). For relative orgunits, it would be very useful to have “parent orgunit”, and “peer orgunits” to include orgunits with the same parent as the user orgunit. Both allow you to have reusable output that can be used to show performance etc relative to related orgunits.
This becomes a bit of a conflict with the “data view org unit” solution. As you know, for users we define one or more “data view” org units, which will define the root of the org unit tree in analysis apps. Often there is a security aspect to this, in the sense that you do not want to allow people to see org units outside that boundary/root. So by allowing for peer/parent data view org units one will violate that principle. Of course we could have Yet Another Setting for this but that is getting more complicated than most people appreciate. I suggest that you simply set the data view org unit for users one level higher up in the hierarchy to achieve this.
That is also the reason I think it would be useful to be able to combine fixed and relative orgunits, so that you could for example have a favorite showing the indicator for your orgunit with the national value.
This we can do. In fact combining relative and fixed org units is already supported in the API so it will be a UI feature. Blueprint:
having spent quite a bit of time in recent months defining output and dashboards, I’ve come across a few gaps that I’d like to highlight.
The first is an issue I also wrote about on the list some time back, which relates to relative periods and “cumulative aggregation” (not sure how to phrase it).Programmes that track progress throughout the year (often with targets), for example EPI, use “months this year” displayed cumulatively as the main way to track progress. By “cumulatively”, I mean that the value for march (whether it is an indicator or data element) would be jan + feb + march, april would be jan + feb + march + april etc.
okay so what you mean is that data should always be cumulative within the year? Meaning it is sort of a “so far this year” report? This is a bit more specific compared to general cumulative function, where one could imagine having cumulative values across relative periods (e.g. last 12 months).
The second issue is support for some additional relative orgunits, and the posibility to combine fixed and relative orgunits (as can be done with periods). For relative orgunits, it would be very useful to have “parent orgunit”, and “peer orgunits” to include orgunits with the same parent as the user orgunit. Both allow you to have reusable output that can be used to show performance etc relative to related orgunits.
This becomes a bit of a conflict with the “data view org unit” solution. As you know, for users we define one or more “data view” org units, which will define the root of the org unit tree in analysis apps. Often there is a security aspect to this, in the sense that you do not want to allow people to see org units outside that boundary/root. So by allowing for peer/parent data view org units one will violate that principle. Of course we could have Yet Another Setting for this but that is getting more complicated than most people appreciate. I suggest that you simply set the data view org unit for users one level higher up in the hierarchy to achieve this.
That is also the reason I think it would be useful to be able to combine fixed and relative orgunits, so that you could for example have a favorite showing the indicator for your orgunit with the national value.
This we can do. In fact combining relative and fixed org units is already supported in the API so it will be a UI feature. Blueprint: