Hi devs,
I’m a bit confused about the way the completeness analytics API works - I suspect there might be a bug when looking at the facility level (i.e. the level where data is entered):
- there is no difference between "not expected to report" and "not reported" - I would expect not reported to be 0 (%) and not expected to report to be blank/null
- facilities with no reports in a particular period is not showing with "expected reports" = 1. This might explain the above point, since they would not have a denominator.
At higher levels, everything works fine - expected is counted correctly. In my case, I’ve tested with a district with 30 facilities, 26 of which is expected to report. Doing a district level request gives actual reports 24, expected 26 for a particular month. However, looking at the individual facilities in that district, the sum of "expected" is 24 and "actual" is 24, thus it is not possible to actually identify which facilities have not reported…
And a related issue: would it make sense to have actual reports be 0 instead of null for facilities that are expected to report, but have not yet reported? Then the completeness is 0/1 = 0% rather than null/1 which is (I guess) null - I would argue that is more "correct".
Hi devs, does anyone have an explanation for this?
Olav
···
23. aug. 2016 kl. 09.52 skrev Olav Poppe <olav.poppe@me.com>:
Hi devs,
I’m a bit confused about the way the completeness analytics API works - I suspect there might be a bug when looking at the facility level (i.e. the level where data is entered):
- there is no difference between "not expected to report" and "not reported" - I would expect not reported to be 0 (%) and not expected to report to be blank/null
- facilities with no reports in a particular period is not showing with "expected reports" = 1. This might explain the above point, since they would not have a denominator.
At higher levels, everything works fine - expected is counted correctly. In my case, I’ve tested with a district with 30 facilities, 26 of which is expected to report. Doing a district level request gives actual reports 24, expected 26 for a particular month. However, looking at the individual facilities in that district, the sum of "expected" is 24 and "actual" is 24, thus it is not possible to actually identify which facilities have not reported…
And a related issue: would it make sense to have actual reports be 0 instead of null for facilities that are expected to report, but have not yet reported? Then the completeness is 0/1 = 0% rather than null/1 which is (I guess) null - I would argue that is more "correct".
it’s a good observation. It is currently a known limitation (for me at least;) of the analytics reporting rate API. Currently it only shows expected reports for where there are at least 1 complete registration.
I am working on it and hope to fix this for 2.25.
Lars
···
On Wed, Aug 31, 2016 at 9:20 AM, Olav Poppe olav.poppe@me.com wrote:
Hi devs, does anyone have an explanation for this?
I’m a bit confused about the way the completeness analytics API works - I suspect there might be a bug when looking at the facility level (i.e. the level where data is entered):
there is no difference between “not expected to report” and “not reported” - I would expect not reported to be 0 (%) and not expected to report to be blank/null
facilities with no reports in a particular period is not showing with “expected reports” = 1. This might explain the above point, since they would not have a denominator.
At higher levels, everything works fine - expected is counted correctly. In my case, I’ve tested with a district with 30 facilities, 26 of which is expected to report. Doing a district level request gives actual reports 24, expected 26 for a particular month. However, looking at the individual facilities in that district, the sum of “expected” is 24 and “actual” is 24, thus it is not possible to actually identify which facilities have not reported…
And a related issue: would it make sense to have actual reports be 0 instead of null for facilities that are expected to report, but have not yet reported? Then the completeness is 0/1 = 0% rather than null/1 which is (I guess) null - I would argue that is more “correct”.