Thanks.. On Tue, Aug 25, 2015 at 9:37 AM, Bharath <chbhara...@gmail.com> 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 <larshe...@gmail.com > > wrote: > >> Hi, >> >> On Tue, Aug 25, 2015 at 9:07 AM, Bharath <chbhara...@gmail.com> 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 < >>> larshe...@gmail.com> 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 <chbhara...@gmail.com> 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 <dapsyjo...@gmail.com >>>>> > 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.hedb...@gmail.com> 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 <chbhara...@gmail.com> 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@lists.launchpad.net >>>>>>>> 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.hedb...@gmail.com >>>>>>> >>>>>>> Skype: calle_hedberg >>>>>>> >>>>>>> ******************************************* >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>>>> Post to : dhis2-devs@lists.launchpad.net >>>>>>> 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@lists.launchpad.net >>>>> 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>
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
