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