dhis2-devs team mailing list archive

[Adedapo Adejumo <dapsyjorge@xxxxxxxxx>]

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
>
>