dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

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

*******************************************