dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

2010/11/18 Bob Jolliffe <bobjolliffe@xxxxxxxxx>

> Can someone define what exactly is an onChange period type?  Its a
> term I have heard referred to a lot but I must confess I don't know if
> I properly understand what it means.  Do we simply mean an arbitrary
> period of time (without frequency) ie. it has start and end date only,
> but no inherent frequency characteristic?  So start date would equal
> the end date of the previous OnChange period for the same series of
> datavalues.  Or is it an instant ie. an observation captured at a
> moment in time with no inherent interval implied?  So
> startdate=enddate?
>
> One case I recall hearing onChange periods being discussed was regard
> staffing data in the context of data import from iHRIS.  The number of
> doctors might change infrequently so we might capture number of
> doctors only when there is a change, rather than capturing the same
> numbers each month.  Either way it raises an interesting problem. I
> think we define the aggregation "operator" (sum, average etc) per data
> element.  But it seems to me, looking at this particular example, that
> you would actually want to aggregate differently depending on which
> axis (time and space) that you were aggregating along.  So for example
> if I have datavalues for "number of doctors" which I collect on a
> monthly report, it makes sense to sum across the spatial axis and
> average across the time axis
>
>               clinicA     clinicB   DistrictTotal
> Jan           5              7            12
> Feb           5              6            11
> Mar           5              5            10
>
> Quarter      5             6             11
>
> Maybe there are other such cases where the aggregation operator would
> differ across different axes.  So there are maybe two ways to
> rationalise this: one is to not capture the data monthly, but rather
> "onChange".  This does have an implication for things like monthly
> data collection instruments, because I suspect frequently there will
> be a requirement to capture such data routinely.  The other is for the
> dataelement to capture the change rather than the cumulative count -
> like we would do with "new malaria cases" for example.  In this case
> we'd capture "new doctors".  In that case we could sum across both
> axes and get a sensible result, but one which would only be useful
> with a sort of opening balance for the dataelement.   So it is not so
> much the period type which is onChange but the dataValue type.  The
> datavalue either reflects what has happened within that period or what
> the cumulative status is at the end of that period.
>
> This is maybe confusing two related issues, but the other approach
> which comes to mind is to have two aggregation operators for the data
> element - the time aggregation operator and the space aggregation
> operator.  This might lead a simple way out of the contradictions and
> complications above.  For many, perhaps most, these would both be
> "sum".  But for others, like the above, we would "sum" over space and
> "average" over time.  I am sure there might be other examples where
> the reverse is true.
>
> I am also sure these are all well known and well solved problems, so
> apologies if I am being ignorant.
>
> Cheers
> Bob
>
> Philosophical aside: Frederick Engels in Anti-Durhring, defines time
> as that quantity required in order for things to change.  I always
> like that definition :-)
>


Quick comment: Currently the aggregation operator property applies to the
time axis only, space axis is always sum.