dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

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:
1.
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.
2.
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@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxx <alejandro.casado@xxxxxxxxxxxxxxxxx>
> – www.msf.org
>
> ------------------------------
> *From:* Barnabas Akumba <akumbabarns@xxxxxxxxx>
> *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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx <alejandro.casado@xxxxxxxxxxxxxxxxx>
> – www.msf.org
>
> ------------------------------
> *From:* Barnabas Akumba <akumbabarns@xxxxxxxxx>
> *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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx <alejandro.casado@xxxxxxxxxxxxxxxxx>
> – www.msf.org
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxx

Skype: calle_hedberg

*******************************************