Thanks..
On Tue, Aug 25, 2015 at 9:37 AM, Bharath wrote:
>
> Have created blueprint:
>
> https://blueprints.launchpad.net/dhis2/+spec/extension-of-analytics-for-completeness-based-on-captured-values-vs-compulsory-fields
>
> We work on this and send you patch, thanks.
>
>
> On Tue, Aug 25, 2015 a
Have created blueprint:
https://blueprints.launchpad.net/dhis2/+spec/extension-of-analytics-for-completeness-based-on-captured-values-vs-compulsory-fields
We work on this and send you patch, thanks.
On Tue, Aug 25, 2015 at 12:43 PM, Lars Helge Øverland
wrote:
> Hi,
>
> On Tue, Aug 25, 2015 at
Hi,
On Tue, Aug 25, 2015 at 9:07 AM, Bharath wrote:
> Thanks Lars, this is perfect.
> Shall I create blueprint for this?
>
Yes that would be good.
> Also any chance that we can include in this version? Thanks
>
>
That depends on how fast you work ;)
cheers
Lars
> On Tue, Aug 25, 2015 at 1
Thanks Lars, this is perfect.
Shall I create blueprint for this? Also any chance that we can include in
this version? Thanks
On Tue, Aug 25, 2015 at 12:21 PM, Lars Helge Øverland
wrote:
> Hi Bharath,
>
> agree with what Calle says above about simply doing values / fields for
> completeness - mig
+1 for including timeliness in analytics. And reporting rate by compulsory data
elements also sounds like a good addition.
Regards
Olav
> 25. aug. 2015 kl. 09.03 skrev Adedapo Adejumo :
>
> Hi Lars,
> This could be a good opportunity to take a closer look at compulsory data
> elements and mov
Hi Lars,
This could be a good opportunity to take a closer look at compulsory data
elements and moving other elements of complete dataset registrations
(timeliness) to the analytics tables. The reporting rate by compulsory data
elements in the reporting rate summary "doesn't work" - a bug was repor
Hi Bharath,
agree with what Calle says above about simply doing values / fields for
completeness - might not be very meaningful.
Also, the approach of storing the value count I don't think will be robust
since in many implementations the forms are not locked after completion,
meaning the count wi
Hi Calle & Adedapo,
Thanks for your views.
@Calle, currently in India we are following the first option entering Zeros
for the services that are not applicable though personally I wont recommend
it as it tremendously increases database size. I can see 70% of data is
zeros in many of the state app
Hi
Thanks Calle for bringing in the data management dimension.
Definitely a tricky issue with no easy solution.
As a start, it will be a great idea to actually get the current
functionality of tagging "compulsory data elements" for datasets and
assessing completeness based on that selection to
Bharath,
The exact method for calculating this aside - it seems to me that a
fundamental limitation in your coverage definition is that it does not
consider whether the data set is an accurate representation of the services
each facility provide. Or in other words, you might have a data set of 100
Hi All,
In India, we have a functionality called Data Entry Status which is to
calculate the coverage of dataentry. For instance a health clinic /
facility which has a monthly dataset of 100 dataelements in which 70
dataelements have been filled then we show 70% as data entry status for
that clini
11 matches
Mail list logo
