dhis2-devs team mailing list archive

[Bharath <chbharathk@xxxxxxxxx>]

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