dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Thanks..

On Tue, Aug 25, 2015 at 9:37 AM, Bharath <chbharathk@xxxxxxxxx> wrote:

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



-- 
Lars Helge Øverland
Lead developer, DHIS 2
University of Oslo
Skype: larshelgeoverland
http://www.dhis2.org <https://www.dhis2.org>