+1 for including timeliness in analytics. And reporting rate by compulsory data elements also sounds like a good addition.
Regards Olav > 25. aug. 2015 kl. 09.03 skrev Adedapo Adejumo <dapsyjo...@gmail.com>: > > Hi Lars, > This could be a good opportunity to take a closer look at compulsory data > elements and moving other elements of complete dataset registrations > (timeliness) to the analytics tables. The reporting rate by compulsory data > elements in the reporting rate summary "doesn't work" - a bug was reported a > while back on this. > Thanks. > > On Tue, Aug 25, 2015 at 7:51 AM, Lars Helge Øverland <larshe...@gmail.com > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <https://launchpad.net/~dhis2-devs> > Post to : dhis2-devs@lists.launchpad.net > <mailto:dhis2-devs@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~dhis2-devs > <https://launchpad.net/~dhis2-devs> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp> > > > > > -- > ******************************************* <> > Calle Hedberg > > 46D Alma Road, 7700 Rosebank, SOUTH AFRICA > > Tel/fax (home): +27-21-685-6472 <tel:%2B27-21-685-6472> > Cell: +27-82-853-5352 <tel:%2B27-82-853-5352> > Iridium SatPhone: +8816-315-19274 <tel:%2B8816-315-19274> > Email: calle.hedb...@gmail.com <mailto:calle.hedb...@gmail.com> > Skype: calle_hedberg > > ******************************************* > > > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > <https://launchpad.net/~dhis2-devs> > Post to : dhis2-devs@lists.launchpad.net > <mailto:dhis2-devs@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~dhis2-devs > <https://launchpad.net/~dhis2-devs> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp> > > > > > > -- > > Regards, > Bharath Kumar. Ch > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > <https://launchpad.net/~dhis2-devs> > Post to : dhis2-devs@lists.launchpad.net > <mailto:dhis2-devs@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~dhis2-devs > <https://launchpad.net/~dhis2-devs> > More help : https://help.launchpad.net/ListHelp > <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/> > > > _______________________________________________ > 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
_______________________________________________ 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
