d2:monthsBetween (date1,date2) gives wrong results

Apparently there is a bug on a program indicator function d2:monthsBetween (date1,date2)

The results produced by a program indicator using the
functionality is not realistic, see the attachment.

I created three program indicators using d2:yearsBetween,
d2:daysBetween and d2:monthsBetween. Apart form d2:monthsBetween, the rest was
producing an expected results.

I created the issue on JIRA: https://jira.dhis2.org/browse/DHIS2-5197?filter=-2

Inline image

Regards

Sele

Good afternoon. First email to the list looking for some help…

We are revising our data model and we have come out with a simplification on the number of Data Elements. For example, before we were using three Data Elements that we have realized they can be joined and then filtered by Organisation Unit when doing the analysis.

This works wonder in data analysis, however we have realized that this will not work for the indicators as there is no possible way of filtering by OU in the indicators. Am I correct? Is there a way that this could be done somehow?

Thanks a lot,

···

Jaime Bosque Torrecilla
Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

**Projects & IT Unit

Médecins Sans Frontières (MSF) Spain – Barcelona Office**

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org

Hello Jaime,

Could you be more detailed? Let’s understand your implementation (eg. of DEs).

Regards

···

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Hello and thanks for the quick response… it seems it might have not been really clear.

I will try to put an example.

We had 3 Data Elements (A,B and C) that have been merged in one (let’s call it X). The reason they have been merged is because A,B and C belong to a Medical Service called Nutrition and as they could be filtered later by that service (Nutrition A, Nutrition B and Nutrition C) it simplified the data input and analysis.

So, for example, now in the OU Nutrition A people will fill the Data Element X. And when doing the analysis they will select Data Element X filtered by service Nutrition A. Same for B and Same for C.

These three indicators were used before separately in several indicators, sometimes we needed A+B+C/100. In those cases we don’t need to do anything as they have already been merged and we can use X/100.

However, and here is the issue. We have realized that when calculating Deaths, the only valid deaths are those coming from Nutrition A and Nutrition B. So before, we would have the indicator Nutrition A + Nutrition B.

Ideally, I would like to be able to create an indicator where Data Elements can be filtered, so I could create an indicator like X (Nutrition A) + X (Nutrition B).

If this is not possible it obliges me to keep the old model with A, B and C separated instead of the X. I hope it is clear… I will happily provide more information if requested.

Thanks,

···

Jaime Bosque Torrecilla
Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

**Projects & IT Unit

Médecins Sans Frontières (MSF) Spain – Barcelona Office**

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org


From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 16:48:02

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

Could you be more detailed? Let’s understand your implementation (eg. of DEs).

Regards

On Tue, Nov 13, 2018 at 4:44 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Good afternoon. First email to the list looking for some help…

We are revising our data model and we have come out with a simplification on the number of Data Elements. For example, before we were using three Data Elements that we have realized they can be joined and then filtered by Organisation Unit when doing the analysis.

This works wonder in data analysis, however we have realized that this will not work for the indicators as there is no possible way of filtering by OU in the indicators. Am I correct? Is there a way that this could be done somehow?

Thanks a lot,

Jaime Bosque Torrecilla
Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

**Projects & IT Unit

Médecins Sans Frontières (MSF) Spain – Barcelona Office**

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.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

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Hello Jaime,

If I understand you correctly, you have three Data Elements that are all disaggregation of a particular Data Element X.

Your initial design was that you created each of the DEs (A, B, C) as individual Data Elements.

My understanding is that you merged them by creating a Category combination with a Data Dimension Type “Disaggregation” A, B and C as options and assigned to the Element Called X. If that is the case, during data entry, the system will disaggregate the Data Element X into X(A), X(B) and X(C).

If you have gone this way, your analysis won’t be an issue.

Please verify and confirm if this is similar to what you want.

Regards

···

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Dear Barnabas,

Thanks a lot for your response. In the end what we were doing is not exactly what you were saying (no Category combinations). So after checking with a couple of colleagues here we realized that this was not a possibility and so we are not merging the data elements in the production environment.

Kind regards,

···

Jaime Bosque Torrecilla
Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

**Projects & IT Unit

Médecins Sans Frontières (MSF) Spain – Barcelona Office**

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org


From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 17:46:26

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

If I understand you correctly, you have three Data Elements that are all disaggregation of a particular Data Element X.

Your initial design was that you created each of the DEs (A, B, C) as individual Data Elements.

My understanding is that you merged them by creating a Category combination with a Data Dimension Type “Disaggregation” A, B and C as options and assigned to the Element Called X. If that is the case, during data entry, the system will disaggregate the Data Element X into X(A), X(B) and X(C).

If you have gone this way, your analysis won’t be an issue.

Please verify and confirm if this is similar to what you want.

Regards

On Tue, Nov 13, 2018 at 5:34 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Hello and thanks for the quick response… it seems it might have not been really clear.

I will try to put an example.

We had 3 Data Elements (A,B and C) that have been merged in one (let’s call it X). The reason they have been merged is because A,B and C belong to a Medical Service called Nutrition and as they could be filtered later by that service (Nutrition A, Nutrition B and Nutrition C) it simplified the data input and analysis.

So, for example, now in the OU Nutrition A people will fill the Data Element X. And when doing the analysis they will select Data Element X filtered by service Nutrition A. Same for B and Same for C.

These three indicators were used before separately in several indicators, sometimes we needed A+B+C/100. In those cases we don’t need to do anything as they have already been merged and we can use X/100.

However, and here is the issue. We have realized that when calculating Deaths, the only valid deaths are those coming from Nutrition A and Nutrition B. So before, we would have the indicator Nutrition A + Nutrition B.

Ideally, I would like to be able to create an indicator where Data Elements can be filtered, so I could create an indicator like X (Nutrition A) + X (Nutrition B).

If this is not possible it obliges me to keep the old model with A, B and C separated instead of the X. I hope it is clear… I will happily provide more information if requested.

Thanks,

Jaime Bosque Torrecilla
Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

**Projects & IT Unit

Médecins Sans Frontières (MSF) Spain – Barcelona Office**

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org

From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 16:48:02

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

Could you be more detailed? Let’s understand your implementation (eg. of DEs).

Regards

On Tue, Nov 13, 2018 at 4:44 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Good afternoon. First email to the list looking for some help…

We are revising our data model and we have come out with a simplification on the number of Data Elements. For example, before we were using three Data Elements that we have realized they can be joined and then filtered by Organisation Unit when doing the analysis.

This works wonder in data analysis, however we have realized that this will not work for the indicators as there is no possible way of filtering by OU in the indicators. Am I correct? Is there a way that this could be done somehow?

Thanks a lot,

Jaime Bosque Torrecilla
Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

**Projects & IT Unit

Médecins Sans Frontières (MSF) Spain – Barcelona Office**

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.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

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba


Jaime and others,

Using category combos (or attribute combos) are fundamentally/conceptually the same as having multiple data elements, because at the end of the day you will have the same number of physical records in your database (e.g. the datavalue table). Or in other words, the level of “granularity” in your data remains the same. (The main advantage in using catcombos is a reduction in the amount of meta-data records you maintain: so instead of creating and maintaining let us say 300 data elements, you create and maintain 50 data elements with 2 gender catoptions and 3 age catoptions (55 meta-data items) → 50x2x3=300 dataelement&catoptioncombos variants. (Maintaining 55 items is presumably easier than 300 - although for many users it’s also more difficult to fully grasp and I have seen a lot of databases where the catcombos have become really messy over the years. Typical examples are multiple changes in e.g. age groups over time).

There are situations where you can use for instance orgunit groups to get “ou-dependent” indicator values, but I would in general not recommend them except when the relation between orgunit(type) and indicator is an inherent and stable dimension of every indicator at a particular orgunit level. A practical example:

If you collect data per hospital, and the hospital have 8 different wards (1 maternity, 2 medical, 2 surgical, 1 paediatrics, 1 ICU, 1 orthopaedics), and you need e.g. Bed Utilisation Rates for each ward type, you would typically create one data element & catcombo set for each type:

Inpatient days - maternity, inpatient days - medical, inpatients separations - maternity, inpatient separations - medical, inpatient death - maternity, inpatient death - medical, etc.

If you on the other hand collect the same data per hospital ward (i.e. expand your orghierarchy to the sub-facility level), and these are grouped per ward type, you need only

inpatient days, inpatient separations, inpatient deaths

and you would do analysis per ou group. NOTE, though, that such a model means you cannot change a ward’s orgunittype without messing up the historic data analysis. So if a ward is changed from a medical to a surgical ward, you would have to close the medical ou and open a surgical ou.

Another perspective on the same is to say that the higher granularity you have in the geographic/administrative dimension (orghierarchy), the less granularity tend to be required in the fact dimension (data elements/indicators). When implementing something like option 2, though, you must also consider aggregation of data - if for instance some of your indicators are using higher level data (e.g. district totals) for some denominators, you might end up struggling to get that.

Jaime do not provide any specifics about exactly what A,B,C is and whether each of them are firmly and permanently bonded to specific outypes only so it is difficult to know if “transferring” some of the granularity to the orgunit dimension is advisable (as indicated above, aggregated analysis needs might also play a role). As a general rule, I would only recommend such shifts if the artifact/event/measurement that the data elements represent is firmly and permanently linked to orgunit types (as is the case with ward-specific indicators) - and even then users have to understand the inherent restrictions like limits to changing the outype group over time. In the case of MSF type health units, it might mean that e.g. an MSF unit grouped under “emergency trauma centre” cannot be kept as the same orgunit if the unit changes from e.g. emergency trauma to long-term rehab. (Not sure if the example is good, but hope you get my drift).

My 2c worth…

Calle

···

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

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


Hi Calle,

Thanks for your 2c worth (we say 20c from where I am from J ). I may be explaining a different perspective here even still being a part of the wider MSF posse but we (the Brussels office) have some indicators (e.g. % of Morbidity / Mortality) that we have created additional related Data Elements that map to the disease e.g. we have different DEs for ‘Malaria’
& for ‘Malaria (death)’ to use for Mortality-type indicators. Mind you this is mapping to the aggregate data capture.

I’m unsure if there are any Best Practices for these types of indicators & how to set them up (I would presume they are common) but if there is any we would be happy to know them & how organisations have configured these.

From reading the below it may be wise to create Cat. Combos instead of additional DE’s but other people may have experience in which is best to capture this & easier to manage over the long term.

Have a good evening,

Damien

···

Jaime and others,

Using category combos (or attribute combos) are fundamentally/conceptually the same as having multiple data elements, because at the end of the day you will have the same number of physical records in your database (e.g. the datavalue table). Or in other words, the level of “granularity” in your data remains the same. (The main advantage in using catcombos is a reduction in the amount of meta-data records you maintain: so instead of creating and maintaining let us say 300 data elements, you create and maintain 50 data elements with 2 gender catoptions and 3 age catoptions (55 meta-data items) → 50x2x3=300 dataelement&catoptioncombos variants. (Maintaining 55 items is presumably easier than 300 - although for many users it’s also more difficult to fully grasp and I have seen a lot of databases where the catcombos have become really messy over the years. Typical examples are multiple changes in e.g. age groups over time).

There are situations where you can use for instance orgunit groups to get “ou-dependent” indicator values, but I would in general not recommend them except when the relation between orgunit(type) and indicator is an inherent and stable dimension of every indicator at a particular orgunit level. A practical example:

If you collect data per hospital, and the hospital have 8 different wards (1 maternity, 2 medical, 2 surgical, 1 paediatrics, 1 ICU, 1 orthopaedics), and you need e.g. Bed Utilisation Rates for each ward type, you would typically create one data element & catcombo set for each type:

Inpatient days - maternity, inpatient days - medical, inpatients separations - maternity, inpatient separations - medical, inpatient death - maternity, inpatient death - medical, etc.

If you on the other hand collect the same data per hospital ward (i.e. expand your orghierarchy to the sub-facility level), and these are grouped per ward type, you need only

inpatient days, inpatient separations, inpatient deaths

and you would do analysis per ou group. NOTE, though, that such a model means you cannot change a ward’s orgunittype without messing up the historic data analysis. So if a ward is changed from a medical to a surgical ward, you would have to close the medical ou and open a surgical ou.

Another perspective on the same is to say that the higher granularity you have in the geographic/administrative dimension (orghierarchy), the less granularity tend to be required in the fact dimension (data elements/indicators). When implementing something like option 2, though, you must also consider aggregation of data - if for instance some of your indicators are using higher level data (e.g. district totals) for some denominators, you might end up struggling to get that.

Jaime do not provide any specifics about exactly what A,B,C is and whether each of them are firmly and permanently bonded to specific outypes only so it is difficult to know if “transferring” some of the granularity to the orgunit dimension is advisable (as indicated above, aggregated analysis needs might also play a role). As a general rule, I would only recommend such shifts if the artifact/event/measurement that the data elements represent is firmly and permanently linked to orgunit types (as is the case with ward-specific indicators) - and even then users have to understand the inherent restrictions like limits to changing the outype group over time. In the case of MSF type health units, it might mean that e.g. an MSF unit grouped under “emergency trauma centre” cannot be kept as the same orgunit if the unit changes from e.g. emergency trauma to long-term rehab. (Not sure if the example is good, but hope you get my drift).

My 2c worth…

Calle

On Wed, 14 Nov 2018 at 16:44, Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Dear Barnabas,

Thanks a lot for your response. In the end what we were doing is not exactly what you were saying (no Category combinations). So after checking with a couple of colleagues here we realized that this was not a possibility and so we are not merging the data elements in the production environment.

Kind regards,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org


From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 17:46:26

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

If I understand you correctly, you have three Data Elements that are all disaggregation of a particular Data Element X.

Your initial design was that you created each of the DEs (A, B, C) as individual Data Elements.

My understanding is that you merged them by creating a Category combination with a Data Dimension Type “Disaggregation” A, B and C as options and assigned to the Element Called X. If that is the case, during data entry, the system will disaggregate the Data Element X into X(A), X(B) and X(C).

If you have gone this way, your analysis won’t be an issue.

Please verify and confirm if this is similar to what you want.

Regards

On Tue, Nov 13, 2018 at 5:34 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Hello and thanks for the quick response… it seems it might have not been really clear.

I will try to put an example.

We had 3 Data Elements (A,B and C) that have been merged in one (let’s call it X). The reason they have been merged is because A,B and C belong to a Medical Service called Nutrition and as they could be filtered later by that service (Nutrition A, Nutrition B and Nutrition C) it simplified the data input and analysis.

So, for example, now in the OU Nutrition A people will fill the Data Element X. And when doing the analysis they will select Data Element X filtered by service Nutrition A. Same for B and Same for C.

These three indicators were used before separately in several indicators, sometimes we needed A+B+C/100. In those cases we don’t need to do anything as they have already been merged and we can use X/100.

However, and here is the issue. We have realized that when calculating Deaths, the only valid deaths are those coming from Nutrition A and Nutrition B. So before, we would have the indicator Nutrition A + Nutrition B.

Ideally, I would like to be able to create an indicator where Data Elements can be filtered, so I could create an indicator like X (Nutrition A) + X (Nutrition B).

If this is not possible it obliges me to keep the old model with A, B and C separated instead of the X. I hope it is clear… I will happily provide more information if requested.

Thanks,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org


From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 16:48:02

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

Could you be more detailed? Let’s understand your implementation (eg. of DEs).

Regards

On Tue, Nov 13, 2018 at 4:44 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Good afternoon. First email to the list looking for some help…

We are revising our data model and we have come out with a simplification on the number of Data Elements. For example, before we were using three Data Elements that we have realized they can be joined and then filtered by Organisation Unit when doing the analysis.

This works wonder in data analysis, however we have realized that this will not work for the indicators as there is no possible way of filtering by OU in the indicators. Am I correct? Is there a way that this could be done somehow?

Thanks a lot,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.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

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba


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

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


Thanks a lot, Calle, for your detailed response. I will share it with the team here.

Best regards,

···

Jaime Bosque Torrecilla
Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

**Projects & IT Unit

Médecins Sans Frontières (MSF) Spain – Barcelona Office**

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org


From: Damien Scarlett

Sent: 14 November 2018 20:16:47

To: calle.hedberg@gmail.com; Jaime Bosque

Cc: DHIS 2 Users list; dhis2-devs

Subject: RE: [Dhis2-users] [Dhis2-devs] Filtering indicators by OU

Hi Calle,

Thanks for your 2c worth (we say 20c from where I am from J ). I may be explaining a different perspective here even still being a part of the wider MSF posse but we (the Brussels office) have some indicators (e.g. % of Morbidity / Mortality) that we have created additional related Data Elements that map to the disease e.g. we have different DEs for ‘Malaria’ & for ‘Malaria (death) ’ to use for Mortality-type indicators. Mind you this is mapping to the aggregate data capture.

I’m unsure if there are any Best Practices for these types of indicators & how to set them up (I would presume they are common) but if there is any we would be happy to know them & how organisations have configured these.

From reading the below it may be wise to create Cat. Combos instead of additional DE’s but other people may have experience in which is best to capture this & easier to manage over the long term.

Have a good evening,

Damien

From: Dhis2-users dhis2-users-bounces+damien.scarlett=brussels.msf.org@lists.launchpad.net On Behalf Of Calle Hedberg

Sent: Wednesday, 14 November 2018 6:02 PM

To: Jaime Bosque Jaime.Bosque@barcelona.msf.org

Cc: DHIS 2 Users list dhis2-users@lists.launchpad.net; dhis2-devs dhis2-devs@lists.launchpad.net

Subject: Re: [Dhis2-users] [Dhis2-devs] Filtering indicators by OU

Jaime and others,

Using category combos (or attribute combos) are fundamentally/conceptually the same as having multiple data elements, because at the end of the day you will have the same number of physical records in your database (e.g. the datavalue table). Or in other words, the level of “granularity” in your data remains the same. (The main advantage in using catcombos is a reduction in the amount of meta-data records you maintain: so instead of creating and maintaining let us say 300 data elements, you create and maintain 50 data elements with 2 gender catoptions and 3 age catoptions (55 meta-data items) → 50x2x3=300 dataelement&catoptioncombos variants. (Maintaining 55 items is presumably easier than 300 - although for many users it’s also more difficult to fully grasp and I have seen a lot of databases where the catcombos have become really messy over the years. Typical examples are multiple changes in e.g. age groups over time).

There are situations where you can use for instance orgunit groups to get “ou-dependent” indicator values, but I would in general not recommend them except when the relation between orgunit(type) and indicator is an inherent and stable dimension of every indicator at a particular orgunit level. A practical example:

If you collect data per hospital, and the hospital have 8 different wards (1 maternity, 2 medical, 2 surgical, 1 paediatrics, 1 ICU, 1 orthopaedics), and you need e.g. Bed Utilisation Rates for each ward type, you would typically create one data element & catcombo set for each type:

Inpatient days - maternity, inpatient days - medical, inpatients separations - maternity, inpatient separations - medical, inpatient death - maternity, inpatient death - medical, etc.

If you on the other hand collect the same data per hospital ward (i.e. expand your orghierarchy to the sub-facility level), and these are grouped per ward type, you need only

inpatient days, inpatient separations, inpatient deaths

and you would do analysis per ou group. NOTE, though, that such a model means you cannot change a ward’s orgunittype without messing up the historic data analysis. So if a ward is changed from a medical to a surgical ward, you would have to close the medical ou and open a surgical ou.

Another perspective on the same is to say that the higher granularity you have in the geographic/administrative dimension (orghierarchy), the less granularity tend to be required in the fact dimension (data elements/indicators). When implementing something like option 2, though, you must also consider aggregation of data - if for instance some of your indicators are using higher level data (e.g. district totals) for some denominators, you might end up struggling to get that.

Jaime do not provide any specifics about exactly what A,B,C is and whether each of them are firmly and permanently bonded to specific outypes only so it is difficult to know if “transferring” some of the granularity to the orgunit dimension is advisable (as indicated above, aggregated analysis needs might also play a role). As a general rule, I would only recommend such shifts if the artifact/event/measurement that the data elements represent is firmly and permanently linked to orgunit types (as is the case with ward-specific indicators) - and even then users have to understand the inherent restrictions like limits to changing the outype group over time. In the case of MSF type health units, it might mean that e.g. an MSF unit grouped under “emergency trauma centre” cannot be kept as the same orgunit if the unit changes from e.g. emergency trauma to long-term rehab. (Not sure if the example is good, but hope you get my drift).

My 2c worth…

Calle

On Wed, 14 Nov 2018 at 16:44, Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Dear Barnabas,

Thanks a lot for your response. In the end what we were doing is not exactly what you were saying (no Category combinations). So after checking with a couple of colleagues here we realized that this was not a possibility and so we are not merging the data elements in the production environment.

Kind regards,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org

From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 17:46:26

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

If I understand you correctly, you have three Data Elements that are all disaggregation of a particular Data Element X.

Your initial design was that you created each of the DEs (A, B, C) as individual Data Elements.

My understanding is that you merged them by creating a Category combination with a Data Dimension Type “Disaggregation” A, B and C as options and assigned to the Element Called X. If that is the case, during data entry, the system will disaggregate the Data Element X into X(A), X(B) and X(C).

If you have gone this way, your analysis won’t be an issue.

Please verify and confirm if this is similar to what you want.

Regards

On Tue, Nov 13, 2018 at 5:34 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Hello and thanks for the quick response… it seems it might have not been really clear.

I will try to put an example.

We had 3 Data Elements (A,B and C) that have been merged in one (let’s call it X). The reason they have been merged is because A,B and C belong to a Medical Service called Nutrition and as they could be filtered later by that service (Nutrition A, Nutrition B and Nutrition C) it simplified the data input and analysis.

So, for example, now in the OU Nutrition A people will fill the Data Element X. And when doing the analysis they will select Data Element X filtered by service Nutrition A. Same for B and Same for C.

These three indicators were used before separately in several indicators, sometimes we needed A+B+C/100. In those cases we don’t need to do anything as they have already been merged and we can use X/100.

However, and here is the issue. We have realized that when calculating Deaths, the only valid deaths are those coming from Nutrition A and Nutrition B. So before, we would have the indicator Nutrition A + Nutrition B.

Ideally, I would like to be able to create an indicator where Data Elements can be filtered, so I could create an indicator like X (Nutrition A) + X (Nutrition B).

If this is not possible it obliges me to keep the old model with A, B and C separated instead of the X. I hope it is clear… I will happily provide more information if requested.

Thanks,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org

From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 16:48:02

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

Could you be more detailed? Let’s understand your implementation (eg. of DEs).

Regards

On Tue, Nov 13, 2018 at 4:44 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Good afternoon. First email to the list looking for some help…

We are revising our data model and we have come out with a simplification on the number of Data Elements. For example, before we were using three Data Elements that we have realized they can be joined and then filtered by Organisation Unit when doing the analysis.

This works wonder in data analysis, however we have realized that this will not work for the indicators as there is no possible way of filtering by OU in the indicators. Am I correct? Is there a way that this could be done somehow?

Thanks a lot,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.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

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba


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

Email: calle.hedberg@gmail.com

Skype: calle_hedberg




Hi Damien!

there is no magic formula for all these config decisions, but one pretty generic good practice would be that the aggregation of your cat. combo options into a data element should be meaningful. As it is the value that users will get when they select the DE in data visualizer or pivot table without details.

From your example: I would say that using two different data elements for Malaria and Malaria (deaths) is correct. If you put them under one unique Malaria DE with a category (cases/deaths), the total number will be mixing cases and deaths, which is most likely incorrect from an analysis point of view and very easy to misinterpret by the users.

Another generic good practice advise is to design your configuration thinking of your desired output (analysis).

Hope it helps!

Marta

···

On Wed, 14 Nov 2018 at 20:17, Damien Scarlett Damien.Scarlett@brussels.msf.org wrote:

Hi Calle,

Thanks for your 2c worth (we say 20c from where I am from J ). I may be explaining a different perspective here even still being a part of the wider MSF posse but we (the Brussels office) have some indicators (e.g. % of Morbidity / Mortality) that we have created additional related Data Elements that map to the disease e.g. we have different DEs for ‘Malaria’
& for ‘Malaria (death)’ to use for Mortality-type indicators. Mind you this is mapping to the aggregate data capture.

I’m unsure if there are any Best Practices for these types of indicators & how to set them up (I would presume they are common) but if there is any we would be happy to know them & how organisations have configured these.

From reading the below it may be wise to create Cat. Combos instead of additional DE’s but other people may have experience in which is best to capture this & easier to manage over the long term.

Have a good evening,

Damien

From: Dhis2-users dhis2-users-bounces+damien.scarlett=brussels.msf.org@lists.launchpad.net On Behalf Of Calle Hedberg

Sent: Wednesday, 14 November 2018 6:02 PM

To: Jaime Bosque Jaime.Bosque@barcelona.msf.org

Cc: DHIS 2 Users list dhis2-users@lists.launchpad.net; dhis2-devs dhis2-devs@lists.launchpad.net

Subject: Re: [Dhis2-users] [Dhis2-devs] Filtering indicators by OU

Jaime and others,

Using category combos (or attribute combos) are fundamentally/conceptually the same as having multiple data elements, because at the end of the day you will have the same number of physical records in your database (e.g. the datavalue table). Or in other words, the level of “granularity” in your data remains the same. (The main advantage in using catcombos is a reduction in the amount of meta-data records you maintain: so instead of creating and maintaining let us say 300 data elements, you create and maintain 50 data elements with 2 gender catoptions and 3 age catoptions (55 meta-data items) → 50x2x3=300 dataelement&catoptioncombos variants. (Maintaining 55 items is presumably easier than 300 - although for many users it’s also more difficult to fully grasp and I have seen a lot of databases where the catcombos have become really messy over the years. Typical examples are multiple changes in e.g. age groups over time).

There are situations where you can use for instance orgunit groups to get “ou-dependent” indicator values, but I would in general not recommend them except when the relation between orgunit(type) and indicator is an inherent and stable dimension of every indicator at a particular orgunit level. A practical example:

If you collect data per hospital, and the hospital have 8 different wards (1 maternity, 2 medical, 2 surgical, 1 paediatrics, 1 ICU, 1 orthopaedics), and you need e.g. Bed Utilisation Rates for each ward type, you would typically create one data element & catcombo set for each type:

Inpatient days - maternity, inpatient days - medical, inpatients separations - maternity, inpatient separations - medical, inpatient death - maternity, inpatient death - medical, etc.

If you on the other hand collect the same data per hospital ward (i.e. expand your orghierarchy to the sub-facility level), and these are grouped per ward type, you need only

inpatient days, inpatient separations, inpatient deaths

and you would do analysis per ou group. NOTE, though, that such a model means you cannot change a ward’s orgunittype without messing up the historic data analysis. So if a ward is changed from a medical to a surgical ward, you would have to close the medical ou and open a surgical ou.

Another perspective on the same is to say that the higher granularity you have in the geographic/administrative dimension (orghierarchy), the less granularity tend to be required in the fact dimension (data elements/indicators). When implementing something like option 2, though, you must also consider aggregation of data - if for instance some of your indicators are using higher level data (e.g. district totals) for some denominators, you might end up struggling to get that.

Jaime do not provide any specifics about exactly what A,B,C is and whether each of them are firmly and permanently bonded to specific outypes only so it is difficult to know if “transferring” some of the granularity to the orgunit dimension is advisable (as indicated above, aggregated analysis needs might also play a role). As a general rule, I would only recommend such shifts if the artifact/event/measurement that the data elements represent is firmly and permanently linked to orgunit types (as is the case with ward-specific indicators) - and even then users have to understand the inherent restrictions like limits to changing the outype group over time. In the case of MSF type health units, it might mean that e.g. an MSF unit grouped under “emergency trauma centre” cannot be kept as the same orgunit if the unit changes from e.g. emergency trauma to long-term rehab. (Not sure if the example is good, but hope you get my drift).

My 2c worth…

Calle

On Wed, 14 Nov 2018 at 16:44, Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Dear Barnabas,

Thanks a lot for your response. In the end what we were doing is not exactly what you were saying (no Category combinations). So after checking with a couple of colleagues here we realized that this was not a possibility and so we are not merging the data elements in the production environment.

Kind regards,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org


From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 17:46:26

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

If I understand you correctly, you have three Data Elements that are all disaggregation of a particular Data Element X.

Your initial design was that you created each of the DEs (A, B, C) as individual Data Elements.

My understanding is that you merged them by creating a Category combination with a Data Dimension Type “Disaggregation” A, B and C as options and assigned to the Element Called X. If that is the case, during data entry, the system will disaggregate the Data Element X into X(A), X(B) and X(C).

If you have gone this way, your analysis won’t be an issue.

Please verify and confirm if this is similar to what you want.

Regards

On Tue, Nov 13, 2018 at 5:34 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Hello and thanks for the quick response… it seems it might have not been really clear.

I will try to put an example.

We had 3 Data Elements (A,B and C) that have been merged in one (let’s call it X). The reason they have been merged is because A,B and C belong to a Medical Service called Nutrition and as they could be filtered later by that service (Nutrition A, Nutrition B and Nutrition C) it simplified the data input and analysis.

So, for example, now in the OU Nutrition A people will fill the Data Element X. And when doing the analysis they will select Data Element X filtered by service Nutrition A. Same for B and Same for C.

These three indicators were used before separately in several indicators, sometimes we needed A+B+C/100. In those cases we don’t need to do anything as they have already been merged and we can use X/100.

However, and here is the issue. We have realized that when calculating Deaths, the only valid deaths are those coming from Nutrition A and Nutrition B. So before, we would have the indicator Nutrition A + Nutrition B.

Ideally, I would like to be able to create an indicator where Data Elements can be filtered, so I could create an indicator like X (Nutrition A) + X (Nutrition B).

If this is not possible it obliges me to keep the old model with A, B and C separated instead of the X. I hope it is clear… I will happily provide more information if requested.

Thanks,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.org


From: Barnabas Akumba akumbabarns@gmail.com

Sent: 13 November 2018 16:48:02

To: Jaime Bosque

Cc: dhis2-users; dhis2-devs

Subject: Re: [Dhis2-devs] Filtering indicators by OU

Hello Jaime,

Could you be more detailed? Let’s understand your implementation (eg. of DEs).

Regards

On Tue, Nov 13, 2018 at 4:44 PM Jaime Bosque Jaime.Bosque@barcelona.msf.org wrote:

Good afternoon. First email to the list looking for some help…

We are revising our data model and we have come out with a simplification on the number of Data Elements. For example, before we were using three Data Elements that we have realized they can be joined and then filtered by Organisation Unit when doing the analysis.

This works wonder in data analysis, however we have realized that this will not work for the indicators as there is no possible way of filtering by OU in the indicators. Am I correct? Is there a way that this could be done somehow?

Thanks a lot,

Jaime Bosque Torrecilla

Applications Technician, eHealth & Operations Applications (‘Apps4OPS’)

Projects & IT Unit Médecins Sans Frontières (MSF) Spain – Barcelona Office

Fixed: +34 935 213 048 – Skype: msfe-healthdatatech2

Email: jaime.bosque@barcelona.msf.org
www.msf.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

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba


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

Email: calle.hedberg@gmail.com

Skype: calle_hedberg



Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-users

More help : https://help.launchpad.net/ListHelp

Hi,

I agree 100% with Marta’s points. The practice of ensuring that all catcombos (and attributecombos) are discrete break-downs of the DE is generally advicable both because it is easier to avoid analytical mistakes and because it’s conceptually easier to explain and “internalise” for users.

That said, HISP-SA had been forced to create a number of exeptions to this general rule:

  • in order to generate stacked graphs for 90-90-90 monitoring, we had to create derived data elements with non-discrete catcombos (so basically a hack because of limitations in current DHIS2 reporting apps)

  • for audit purposes, where facilities are revisited and the same data collated & captured again, we also ended up using non-discrete catcombos (original data, audit data, discrepancy between the two)

but those are special cases.

A common mistake related to attributeoptioncombos are when attrributeoptioncombos are used to capture data from different partners for the same orgunit - so e.g. the Ministry, MSF, PSI, and Red Cross are all supporting the same facility. Then it is critical to ensure that the different partners do not collate data for the same events/patients (aka several partners “claim” the same patients because they do provide SOME part of the total service delivery). So multiple partners provide services to the same patients, it might be necessary to represent that using different DEs, otherwise you end up doubling or tripling data (you do remember the case for Botswana discovered by the New York Times a few years ago, where PEPFAR claimed they supported ~16,000 ART patients in Botswana - whereas they had actually only supported some workshops for the Ministry staff providing ART services…)

The boundary between what’s covered in the orghierarchy dimension and what covered in the fact dimension also depend on what your ou reporting units are. As an example, let us consider deaths from trauma in a conflict situation. You might want to differentiate between

  • deaths before anybody finds/attends the patient (“Trauma - dead on site”). Those numbers are useful only for sensitisation etc.

  • deaths while under EMRS care (“Trauma - dead on arrival”). Ditto use, but also relevant to analyse EMRS equipment & staff skills + EMRS effectiveness (no of ambulances, speed of transport)

  • deaths while under the care of health personnel in a health facility (“Trauma - death”). Relevant for general sensitisation like the above, but also for analysing quality of care, capacity, equipment/blood supplies, and similar.

How many data elements you need for the above will depend on e.g. if EMRS ambulances are separate reporting units - if yes, they will presumable report on the first two types above.

Beyond the basic death due to trauma, you might then use catcombos to break those down into other discrete categories e.g. Trauma due to gunshots, due to IEDs, due to bombing, due to physical assault, etc etc. OR you might want sub-divide deaths into patient characteristics (age, gender, soldier/civilian, resident/refugee, etc). Most such break-downs can be handled through catcombos as long as the category options are discrete - if they are not, I would in general create separate Data elements.

As your DE granularity grows, you should also consider moving to case-based data collection (possible even a full EMR system) with diagnosis, procedures, outcomes etc - which enables more detailed data mining. You can see that the small example above increasingly start looking like a list of ICD-10 trauma codes…

Regards

Calle

···

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

Email: calle.hedberg@gmail.com

Skype: calle_hedberg