dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

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>