dhis2-devs team mailing list archive

[Adedapo Adejumo <dapsyjorge@xxxxxxxxx>]

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 reported
a while back on this.
Thanks.

On Tue, Aug 25, 2015 at 7:51 AM, Lars Helge Øverland <larshelge@xxxxxxxxx>
wrote:

> 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 will be off if additional data is entered or removed.
>
> To me, the ideal solution here is to implement this in analytics and base
> it on compulsory data elements. We already have reporting rates based on
> completeness registrations in analytics. We could extend this with
> completeness based on captured values vs compulsory fields (like we do for
> the "reporting rate summary" under reports).
>
> That way, you can now take advantage of the flexibility of analytics in
> terms of dimensions (rows, columns, filters), relative periods, org units
> etc, without having to re-implement all that. You could then build your app
> on top of the analytics api.
>
> Let me know what you think.
>
> best regards,
>
> Lars
>
>
>
>
>
>
>
>
> On Mon, Aug 24, 2015 at 4:52 AM, Bharath <chbharathk@xxxxxxxxx> wrote:
>
>>
>> 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 applications. The second option can
>> workout for instances where we have some legacy but not for newly started
>> ones.
>>
>> I agree with Adedapo to start with calculating coverage for compulsory
>> dataelements.
>>
>>
>>
>> On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo <dapsyjorge@xxxxxxxxx>
>> wrote:
>>
>>> 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 work and then work on
>>> making this smarter - the ability to define compulsory data elements for
>>> organisation unit groups .
>>> The customization of data entry forms along the lines of service
>>> availability/provision will be the gold standard but implementation may be
>>> tricky in some circumstances and environments.
>>>
>>> On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg <calle.hedberg@xxxxxxxxx
>>> > wrote:
>>>
>>>> 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
>>>> data elements used for let us day 200 facilities - in many/most countries,
>>>> it would be uncommon for all 200 facilities to provide ALL the services
>>>> represented in those 100 data elements.
>>>>
>>>> The net result is that you data entry coverage status will most likely
>>>> always be well under 100% - even if every single facility report fully for
>>>> every data element covering services that they DO provide.
>>>>
>>>> There are at least two options for dealing with this:
>>>>
>>>> 1. You can enforce the capture of a zero for all services a facility do
>>>> not provide.
>>>> 2. You generate the data entry coverage rate based on Filled data items
>>>> divided by "Actual" data items - the latter derived from a longer term
>>>> (12-18 months) pattern analysis, where you can set a threshold for when a
>>>> data item is regarded as "active" (meaning that service is actually
>>>> regularly provided) for a specific facility.
>>>>
>>>> The main disadvantage of the first method is that managers will not
>>>> know whether a 0 means that service is not provided at all, or whether it
>>>> IS available but that there were no cases for that month.
>>>>
>>>> We (South Africa) are currently discussing a related method for the
>>>> customisation of the data entry form itself. SA is using relatively
>>>> standardised data sets across a large variety of facilities (e.g. a
>>>> "Clinic" might vary from a single-nurse facility doing basic preventative
>>>> care only to a large one-stop facility with 10-20 nurses and a few doctors
>>>> providing a nearly full range of PHC services). Users would like to have a
>>>> way of automatically reducing the size of the data entry form to only show
>>>> data elements relevant for each facility - and one suggestion has been to
>>>> only display data elements that have actual data stored for the previous
>>>> 12-18 months (with a "More" button to display additional data elements when
>>>> required).
>>>>
>>>> We should work towards a more uniform model for handling these data
>>>> entry and coverage aspects - a model that BOTH provide feedback on data
>>>> entry completeness AND feedback to managers on what services are actually
>>>> provided at which facilities. The first aspect is primarily an HMIS issue -
>>>> the second aspect is the more fundamental service delivery issue.
>>>>
>>>> Regards
>>>> Call
>>>>
>>>>
>>>>
>>>> On 21 August 2015 at 23:51, Bharath <chbharathk@xxxxxxxxx> wrote:
>>>>
>>>>> 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 clinic. Data entry status coverage can be calculated for multiple
>>>>> orgunits and for multiple periods for a selected dataset. This
>>>>> functionality was developed as a Java module. Now we are working on
>>>>> converting this functionality into an App.
>>>>>
>>>>> While working on App we had thought of 2 options to get this
>>>>> functionality working:
>>>>>
>>>>> Option 1 is getting all data for each clinic and each period using
>>>>> webapi request and divide by number of dataelements (including category
>>>>> option combos) and mulitplying with 100 to get percentage for each clinic
>>>>> and for each period. Formula is
>>>>>
>>>>> Filled Data Items
>>>>> -------------------------   X 100
>>>>> Total Data Items
>>>>>
>>>>> But making webapi request to get all data seems expensive as we really
>>>>> don't need data we just need the count.
>>>>>
>>>>> So another option (Option2) is extending Complete Data Set
>>>>> Registration functionality, when user clicks on complete button we can also
>>>>> calculate how many items are filled and we can store in the same object.
>>>>> Meaning we can add one more property / column to Complete DataSet
>>>>> Registration say filledDataItemCount.
>>>>>
>>>>> We would prefer this option, please let us know if this extension is
>>>>> agreeable to be part of core, if yes we can work on this and can send patch
>>>>> file.
>>>>>
>>>>> If there are any other solutions please share, Thanks
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Regards,
>>>>> Bharath Kumar. Ch
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *******************************************
>>>>
>>>> Calle Hedberg
>>>>
>>>> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>>>>
>>>> Tel/fax (home): +27-21-685-6472
>>>>
>>>> Cell: +27-82-853-5352
>>>>
>>>> Iridium SatPhone: +8816-315-19274
>>>>
>>>> Email: calle.hedberg@xxxxxxxxx
>>>>
>>>> Skype: calle_hedberg
>>>>
>>>> *******************************************
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Regards,
>> Bharath Kumar. Ch
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Lars Helge Øverland
> Lead developer, DHIS 2
> University of Oslo
> Skype: larshelgeoverland
> http://www.dhis2.org <https://www.dhis2.org>
>
>