dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

I think Ola's example is a pretty typical one and certainly one that
meets most of the requirements here.

>To me this rules out re-using the same dimensional attributes for data
> entry and analysis - we must in any case have on set of dimensions for data
> entry and one set of dimensions for analysis.

Yes, I agree with this to some extent.  I think that categories should
be confined to data entry, which is a clearly a requirement, but not
an absolute one. Non-multidimensional data elements could be employed
for the same purpose it would seem.  I would think they may need
special methods like ordering on a screen, which points to more of an
implementation of an object, than the object itself.
Multidimensional data elements can be assigned cateogries for the
purpose of data entry, which would not be able to be deleted, but
could perhaps be added to, once data has been entered. I suppose
categories could be deleted, with the data being deleted as well?
Seems complicated, but maybe this has been considered during the
original implementation.  I agree , they should be able to be assigned
additional DimensionOptions, after the fact. CategoriesOptions and
DimensionOptions should be invisible to the end-user. Likewise, data
elements that have not been assigned categories for the purpose of
data entry, should be able to be assigned DimensionOptions at any
point in time. Thus, CateogryOptions and DimensionOptions would be
drawn from the same data source potentially, but used for different
purposes.

>
> c) Ola's suggested solution supports this. It is powerful in the ability to
> assign "raw" DataElements to Dimensions/GroupSets through
> DimensionOptions/Groups, completely independent of which Categories the
> DataElement was assigned to for data entry. The weakness is that it is based
> on flat data elements, not Categorized data elements, which we must include
> if we are to justify the Categorized data entry.

I think there is clear justification, as Johan has pointed out. It
makes life easier in some cases, but I see a potential problem when it
comes around to changing a multidimensional data element which
inevitably happens all the time. Disaggregation is changed from time
to time, which will force implementers that have chosen to go down the
multidimensional route, to create new data elements somehow, with
different category options. But if you want to compare these
longitudinally across the change in CateogryOptions, this could be
done by assigning correct DimensionOptions if necessary, perhaps?
>


> This way we can assign dimensions as we like without loosing the fine
> granularity of the captured categorized data. We can improve the report
> table functionality in order to utilize this. This will be feasible with the
> time and resource constraints we are operating with. It also alleviates the
> challenge regarding Indicators and SDMX.

Perhaps. I am not familiar yet with how SDMX implements indicators.
However, it is clear from our experience with the OpenHealth prototype
that not all data elements or indicators are intrinsically
multidimensional. Some of the indicators from the UNGASS are
devilishly complex, like the NCPI index. DHIS 2 gets around this
problem with the use of formulas. Take the indicator "Couple year
protection rate", which is defined in my system as [103.16] / 13 +
[104.16] / 4 + [105.16] / 6 + [107.16] * 10 + [106.16] * 5 + [108.16]
* 10 + [109.16] * 10...a lot of data elements divided/multiplied by
certain factors. This would never be multidimensional and SDMX will
have to transport this "indicator logic" with it.

The main use of the DimensionOptions/CategoryOptions for me would be
for ad-hoc analysis, OLAP cubes, and other "analysis" purposes. I
guess SDMX would need to be able transport both multdimensional
indicators (which are defined with multidimensional data elements or
non-multidimensional data elements that have been assigned
DimensionOptions), but these will not cover all indicators .Usually,
indicators themselves are not going to be sliced and diced with
PivotTables in the same way as data elements, which may be brought
into a PivotTable in order to calculate an ad-hoc indicator. If we
could utilize the DimensionOptions with indicators for this purpose,
it might be very useful to calculate things like "Under 5 malaria
mortality rate" as a slice of the indicator "Malaria mortality rate",
but for some indicators (as illustrated above) this is not going to be
possible.


Best regards,
Jason