Thanks Lars, this is perfect. Shall I create blueprint for this? Also any chance that we can include in this version? Thanks
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
_______________________________________________ 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