dhis2-devs team mailing list archive

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

Hi Lars,
Thanks for the answer. I suppose this is really something I never noticed.
We have had data for a long time in the system for legacy data elements
which was collected on a quarterly basis, and then later on on a monthly
basis. It seemed to work fine, but this could have just been a fluke.

If this is the case, then it would seem to be the period type should
actually be associated with the data element in this case. Attempting to
derive it from it association with a data set would seem dubious. Not sure
if a data integrity check is in place for this, but we should certainly
warn the user that when a data elements belongs to two data sets of
different frequencies, then weird stuff may happen.

Something just does not feel right about this though I must say. I had
though all along that it was no problem to collect the data data element
with different frequencies, similar to how it is possible to collect the
same data element at differing orgunit levels. And it would seem that the
analytics simply does not perform this check at all, which explains the
difference I was noticing between the aggregated data from the datamart and
the aggregated data from the analytics.

Regards,
Jason



On Tue, May 14, 2013 at 1:34 PM, Lars Helge Øverland <larshelge@xxxxxxxxx>wrote:

> Hi Jason
>
>
> On Sat, May 11, 2013 at 8:16 PM, Jason Pickering <
> jason.p.pickering@xxxxxxxxx> wrote:
>
>> Hi Lars,
>> This has never been an issue before. It has only recently ( I think in
>> 2.11) been noticed. Perhaps it has just gone undetected until now.
>>
>> I guess what is really puzzling is that it "seems" work fine for the new
>> PivotTables. Anything which depends on the datamart does not work, so the
>> logic does not seem to be consistent. What I mean my "seems", is that I
>> have not confirmed in the values which appear in the analytics actually sum
>> to what they "should", in this case that the weekly and monthly values
>> should be summed. There of course could be other situations (similar to the
>> "Aggregation levels") in which weekly data (higher frequency) and monthly
>> data (lower frequency) data should not be summed at all (which does not
>> seem to be accounted for).
>>
>> I guess what I am missing really is the relationship between a dataset
>> and a data value, and perhaps  a data element. One could think of a data
>> warehousing situation when in fact there is not a dataset for a data
>> element, unless this is implicitly required (as is perhaps indicated with
>> the Data Integrity checks?) Perhaps it is never entered through the data
>> entry screen at all, but simply imported from an external system.
>>
>
>
> I remember there was a long discussion about this some years ago about
> whether to define collection frequency explicitly for each data element or
> implicitly through data set associations. The advantages of the latter are
> that data elements are not directly coupled with the frequency they are
> collected, and that this model itself allows for multiple capturing
> frequencies. The downside is like you point out that there has to be data
> sets for data elements, even if they are not collected through DHIS 2. So
> we went for the latter with these in mind.
>
>
>> One could also think of situations where data elements are recorded at
>> different frequencies. This is exactly what is happening here in Zambia,
>> where certain data elements are reported weekly on some datasets,
>> and monthly in others. In this case, they are for different orgunits,
>> whereby certainly orgunits report weekly and others report monthly.
>>
>>
> Yes and we admittedly don't support this well. Of course it could be done,
> but it would be complex. The issue is still that we cannot allow
> disaggregation. So if a branch of the org unit tree captures something
> weekly while the rest captures monthly, then we could produce weekly
> reports for org units within that branch, but not outside it. Something to
> consider.
>
> Lars
>
>
>