dhis2-devs team mailing list archive

[Bharath <chbharathk@xxxxxxxxx>]

Have created blueprint:
https://blueprints.launchpad.net/dhis2/+spec/extension-of-analytics-for-completeness-based-on-captured-values-vs-compulsory-fields

We work on this and send you patch, thanks.


On Tue, Aug 25, 2015 at 12:43 PM, Lars Helge Øverland <larshelge@xxxxxxxxx>
wrote:

> Hi,
>
> On Tue, Aug 25, 2015 at 9:07 AM, Bharath <chbharathk@xxxxxxxxx> wrote:
>
>> Thanks Lars, this is perfect.
>> Shall I create blueprint for this?
>>
>
> Yes that would be good.
>
>
>> Also any chance that we can include in this version? Thanks
>>
>>
> That depends on how fast you work ;)
>
> cheers
>
> Lars
>
>
>> 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
>>
>
>
>
> --
> Lars Helge Øverland
> Lead developer, DHIS 2
> University of Oslo
> Skype: larshelgeoverland
> http://www.dhis2.org <https://www.dhis2.org>
>
>


-- 

Regards,
Bharath Kumar. Ch