Extending Complete DataSet Registration

Support - Assistance technique
1

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

2

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 chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

3

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.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

4

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 dapsyjorge@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.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

Regards,
Bharath Kumar. Ch

5

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 chbharathk@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.

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

–

On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo dapsyjorge@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.

–

Regards,
Bharath Kumar. Ch

On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg calle.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

6

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 larshelge@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 chbharathk@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.

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

On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo dapsyjorge@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.

–

Regards,
Bharath Kumar. Ch

On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg calle.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

7

+1 for including timeliness in analytics. And reporting rate by compulsory data elements also sounds like a good addition.

Regards

Olav

···

On Tue, Aug 25, 2015 at 7:51 AM, Lars Helge Øverland larshelge@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 chbharathk@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.

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

On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo dapsyjorge@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.

–

Regards,
Bharath Kumar. Ch

On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg calle.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

8

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 larshelge@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 chbharathk@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.

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

On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo dapsyjorge@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.

–

Regards,
Bharath Kumar. Ch

On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg calle.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

Regards,
Bharath Kumar. Ch

9

Hi,

···

On Tue, Aug 25, 2015 at 9:07 AM, Bharath chbharathk@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 :wink:

cheers

Lars

–

On Tue, Aug 25, 2015 at 12:21 PM, Lars Helge Øverland larshelge@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

–

Regards,
Bharath Kumar. Ch

On Mon, Aug 24, 2015 at 4:52 AM, Bharath chbharathk@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.

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

On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo dapsyjorge@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.

–

Regards,
Bharath Kumar. Ch

On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg calle.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

10

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 larshelge@gmail.com wrote:

Hi,

–

On Tue, Aug 25, 2015 at 9:07 AM, Bharath chbharathk@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 :wink:

cheers

Lars

–
Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Aug 25, 2015 at 12:21 PM, Lars Helge Øverland larshelge@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

–

Regards,
Bharath Kumar. Ch

On Mon, Aug 24, 2015 at 4:52 AM, Bharath chbharathk@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.

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

On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo dapsyjorge@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.

–

Regards,
Bharath Kumar. Ch

On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg calle.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

Regards,
Bharath Kumar. Ch

11

Thanks…

···

On Tue, Aug 25, 2015 at 9:37 AM, Bharath chbharathk@gmail.com wrote:

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 larshelge@gmail.com wrote:

Hi,

–

Regards,
Bharath Kumar. Ch

On Tue, Aug 25, 2015 at 9:07 AM, Bharath chbharathk@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 :wink:

cheers

Lars

–
Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Aug 25, 2015 at 12:21 PM, Lars Helge Øverland larshelge@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

–

Regards,
Bharath Kumar. Ch

On Mon, Aug 24, 2015 at 4:52 AM, Bharath chbharathk@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.

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

On Mon, Aug 24, 2015 at 4:50 AM, Adedapo Adejumo dapsyjorge@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.

–

Regards,
Bharath Kumar. Ch

On Sat, Aug 22, 2015 at 11:06 AM, Calle Hedberg calle.hedberg@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.
  1. 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

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

On 21 August 2015 at 23:51, Bharath chbharathk@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.hedberg@gmail.com

Skype: calle_hedberg

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org