dhis2-devs team mailing list archive

[Bharath <chbharathk@xxxxxxxxx>]

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


-- 

Regards,
Bharath Kumar. Ch