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
