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